自动报表失败后，谁来接手？
文档明确的机制
自动报表跑失败时，n8n 文档给出的核心机制是 error workflow（错误工作流）。它的作用是控制工作流执行失败时 n8n 如何响应。设置位置在每个工作流的 Workflow Settings 中：为某个工作流选择一个错误工作流后，当该工作流执行失败，关联的错误工作流就会运行。文档举例说明，它可以用于在工作流出错时发送 email 或 Slack 告警。
错误工作流有一个明确入口要求：必须以 Error Trigger 作为第一个节点。设置步骤也比较直接：先新建工作流，把 Error Trigger 放在首位，命名并保存；再进入需要监控的工作流，通过 Options > Settings，在 Error workflow 中选择刚保存的错误工作流并保存。同一个错误工作流可以被多个工作流复用，因此团队可以用统一入口接收不同自动化流程的失败通知。
错误工作流收到的数据也有文档定义。默认情况下，Error Trigger 会收到执行信息与工作流信息，包括：
execution.id、execution.urlexecution.retryOfexecution.error.message、execution.error.stackexecution.lastNodeExecutedexecution.modeworkflow.id、workflow.name
这些字段并非在所有场景都完整存在。文档说明，除特别列出的字段外，信息通常都会存在；execution.id 和 execution.url 要求执行已保存到数据库，如果错误发生在主工作流的触发器节点，主工作流并未实际执行，这两个字段就不会出现。execution.retryOf 只在本次执行是某次失败执行的重试时出现。
如果失败由主工作流的触发器节点引起，传给错误工作流的数据结构会不同：execution{} 中的信息更少，并包含更多 trigger{} 信息。文档示例中有 trigger.error、trigger.mode，以及 workflow.id、workflow.name 等结构。因此，排查自动报表问题时，不能假定所有失败消息都带有执行 URL，也不能假定一定能通过执行 ID 回看原执行。
文档还提供了一个主动制造失败的节点：Stop and Error。当已经创建并设置错误工作流后，可在指定条件下用该节点强制工作流失败，从而触发错误工作流。文档提到，执行失败通常可能来自节点设置错误或工作流内存耗尽等情况；Stop and Error 则适合把团队定义的异常条件显式转入错误处理流程。
团队自行约定的接手建议
以下是团队接手建议，不是 n8n 文档声明的产品能力。
错误工作流解决的是“失败后自动触发处理流程”，但“谁来接手”仍需要团队自行约定。建议在告警内容中至少带上文档能提供的关键信息：报表工作流名称、最后执行节点、错误消息、错误堆栈、执行模式，以及存在时的执行 URL。若 execution.url 缺失，接手人应知道这可能是触发器节点失败或执行未保存，而不是告警漏发。
告警接收渠道可以由团队通过错误工作流自行连接，例如文档举例的 email 或 Slack。但谁在工作时间响应、谁在非工作时间备份、多久确认，都应在团队值班规则中写清楚。否则错误工作流只能把失败发出去，不能保证有人处理。
对于“自动报表失败后是否重跑”，也建议由团队明确操作口径。原文只说明错误数据中可能出现 retryOf，用于表示本次执行是失败执行的重试；文档没有在本页给出自动重试策略、重试次数或重试配置。因此，不应把 error workflow 理解为自动补偿系统。团队可自行规定：接手人先查看执行记录和错误节点，再决定是否手动重试；如果要做自动重试，需要另行设计并验证流程，不能声称这是本页文档列出的内置机制。
成本范围同样要单独约定。原文没有列出错误工作流的计费、额度或调用成本，因此文章不能据此推断“失败处理免费”或“告警不会产生额外费用”。团队若使用外部消息服务或其他节点，应按自己的部署与服务合同核查。
边界与总结
n8n 文档明确支持的是：为工作流配置错误工作流；错误工作流必须从 Error Trigger 开始；执行失败时运行；可发送 email 或 Slack 告警；可复用；可接收执行和工作流错误数据；触发器节点失败时数据结构不同；Stop and Error 可在自定义条件下强制失败并触发错误工作流。
文档还提到，调查失败执行时可以查看 Executions，也可以从之前的执行加载数据到当前工作流，并可启用 Log streaming。这些能力有助于排查，但并不能替代团队定义值班、升级、人工确认和重试规则。
因此，自动报表失败后的接手应分成两层：产品机制负责按文档触发错误工作流并传递错误数据；团队制度负责决定告警发给谁、谁确认、如何排查、能否重跑以及如何记录处理结果。 把这两层分开，才能避免把“收到告警”误认为“已经有人接手”，也避免补写文档未提供的重试或费用承诺。
立即实践
体验现有 AI 工作流 ROI 诊断器，验证上述工作流的输入、结果与下一步操作。此 Demo 是相关实践工具，不代表原项目的完整实现。