# 自动报表失败后，谁来接手？

## 文档明确的机制

自动报表跑失败时，n8n 文档给出的核心机制是 **error workflow（错误工作流）**。它的作用是控制工作流执行失败时 n8n 如何响应。设置位置在每个工作流的 **Workflow Settings** 中：为某个工作流选择一个错误工作流后，当该工作流执行失败，关联的错误工作流就会运行。文档举例说明，它可以用于在工作流出错时发送 email 或 Slack 告警。

错误工作流有一个明确入口要求：必须以 **Error Trigger** 作为第一个节点。设置步骤也比较直接：先新建工作流，把 Error Trigger 放在首位，命名并保存；再进入需要监控的工作流，通过 **Options > Settings**，在 **Error workflow** 中选择刚保存的错误工作流并保存。同一个错误工作流可以被多个工作流复用，因此团队可以用统一入口接收不同自动化流程的失败通知。

错误工作流收到的数据也有文档定义。默认情况下，Error Trigger 会收到执行信息与工作流信息，包括：

- `execution.id`、`execution.url`
- `execution.retryOf`
- `execution.error.message`、`execution.error.stack`
- `execution.lastNodeExecuted`
- `execution.mode`
- `workflow.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 诊断器](/demos/ai-workflow-roi-diagnostic/index.html)，验证上述工作流的输入、结果与下一步操作。此 Demo 是相关实践工具，不代表原项目的完整实现。


来源：[自动报表失败后，谁来接手？](https://docs.n8n.io/build/flow-logic/handle-errors-gracefully.md)