# n8n 错误工作流：Error Trigger、重试与 Stop And Error > n8n 的错误工作流是一个单独的工作流，以 Error Trigger 节点开头，在另一个工作流的自动执行失败时运行。你在每个工作流的设置里指定它，一个处理器可以服务很多工作流。在一次运行内部，每个节点的重试和出错设置决定失败怎么处理，Stop And Error 则能主动让一次运行失败。 Mindket 编辑部 · 发布于 2026-11-04 · 更新于 2026-11-05 · https://mindket.com/cn/learn/n8n-advanced/n8n-error-handling ## 要点 - 用 Error Trigger 搭一个错误工作流，并在工作流设置里指定它。 - 看懂它收到的错误数据，包括触发器节点失败时数据结构的不同。 - 为每个节点在 Retry On Fail、Continue 和 Continue (using error output) 之间做选择。 - 数据不对却没有节点报错时，用 Stop And Error 主动让这次运行失败。 ## 开始之前 本课跟的是 2026 年 11 月 4 日的 n8n 文档，默认你已经学过[第一个工作流](https://mindket.com/cn/learn/n8n/n8n-first-workflow)那一课：会搭工作流、会发布、会看执行记录。错误工作流只对自动运行起反应，所以被它监控的工作流需要一个不用你动手就会触发的触发器，比如定时或 Webhook，并且必须已经发布。 有一个设置决定了处理器能报告多少内容。文档说，`execution.id` 和 `execution.url` 只有在执行记录保存到数据库时才存在，所以凡是要发告警的工作流，都把 **Save failed production executions** 保持开启。 ## 搭建处理器并接到工作流上 处理器就是一个普通的工作流，第一个节点是 Error Trigger。下面这条消息是为本课写的示例，用的是文档里数据结构的字段名。把它放进接在触发器后面的 Slack 或 Send Email 节点： ````text Workflow failed: {{ $json.workflow.name }} Last node: {{ $json.execution.lastNodeExecuted }} Error: {{ $json.execution.error.message }} Execution: {{ $json.execution.url }} ```` 1. 新建一个工作流，把 **Error Trigger** 节点加为第一个节点。 2. 给它起个名字，比如 `Error Handler`，然后选择 **Save**。[Error Trigger 页面](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.errortrigger)说，用了这个节点的工作流不需要发布。 3. 在触发器后面加一个通知节点，比如 Slack 或 Send Email，把上面的示例粘贴成消息内容。 4. 打开要监控的工作流。在工作流菜单里选择 **Settings**，在 **Error workflow (to notify when this one errors)** 下选中你的处理器，再选择 **Save**。 5. 给被监控的工作流造一个随时可触发的失败：一个 Schedule Trigger 后面接一个 Stop And Error 节点，并发布。本课最后一节会讲这个节点。 6. 定时触发之后，打开处理器的 Executions 标签，看它收到了什么。在被监控的工作流上点 Execute workflow 说明不了任何事，因为 Error Trigger 只在自动执行出错时才运行。 ## Error Trigger 会收到什么 默认情况下，触发器收到的是一个数组，里面有一个 `execution` 对象和一个 `workflow` 对象，见下面[错误处理指南](https://docs.n8n.io/build/flow-logic/handle-errors-gracefully)里给出的数据。 主工作流自己的触发器节点失败时，结构会变。这时工作流根本没有执行，所以 `execution` 里的内容变少，细节放进了 `trigger` 对象：一个 `error`，带有 `WorkflowActivationError` 这样的名称、消息、原因、时间戳和节点，另外 `mode` 是 `trigger`。读取 `execution.error.message` 的处理器，需要为这种情况再加一条分支。 ````json [ { "execution": { "id": "231", "url": "https://n8n.example.com/execution/231", "retryOf": "34", "error": { "message": "Example Error Message", "stack": "Stacktrace" }, "lastNodeExecuted": "Node With Error", "mode": "manual" }, "workflow": { "id": "1", "name": "Example Workflow" } } ] ```` | 字段 | 什么时候没有 | 原因 | | --- | --- | --- | | `execution.id`、`execution.url` | 错误出在主工作流的触发器节点 | 工作流根本没运行，而且这两个字段都需要已保存的执行记录 | | `execution.retryOf` | 这次执行不是重试 | 只有这次运行是在重试一次失败的执行时才出现 | | `trigger` | 错误不在触发器节点 | 触发器失败时，细节放在这里，`mode` 为 `trigger` | ## 一次运行内部的失败：重试与 On Error 错误工作流是在一次执行已经失败之后才行动，节点设置则出手更早。打开节点的 Settings 标签，能看到 **Retry On Fail** 和 **On Error**，[文档](https://docs.n8n.io/build/understand-workflows/workflow-components/work-with-nodes)对它们各用一行话描述。 Retry On Fail 那一行说节点会一直重跑到成功。[执行引擎的源码](https://github.com/n8n-io/n8n/blob/master/packages/core/src/execution-engine/workflow-execute.ts)划的线更紧：`maxTries` 默认是 3，限制在 2 到 5 之间，`waitBetweenTries` 默认是 1000 毫秒，限制在 0 到 5000 之间。根据编辑器的[英文字符串](https://github.com/n8n-io/n8n/blob/master/packages/frontend/@n8n/i18n/src/locales/en.json)，这两项在界面上叫 Max. Tries 和 Wait Between Tries (ms)。重试能解决自己会消失的超时或限流，换成错误的 API 密钥，每次都会以同样的方式失败。 On Error 有三个取值。Continue 在源码里藏着一个陷阱：节点自己抛出错误时，n8n 把这个节点的输入数据交给下一个节点，于是后面的流程接着跑在失败节点根本没处理过的数据上。而且这次运行最后没有失败，错误工作流也就不会出声。 **On Error 的每个选项会怎样** | | Stop Workflow | Continue | Continue (using error output) (我们的选择) | | --- | --- | --- | --- | | 让执行失败，错误工作流因此运行 | ✓ 是 | ✗ 否 | ✗ 否 | | 失败节点之后的节点继续运行 | ✗ 否 | ✓ 是 | ✓ 是 | | 失败的数据项从额外的错误输出口送出 | ✗ 否 | ✗ 否 | ✓ 是 | **我们的选择：Continue (using error output)。** 失败的数据项有了自己的分支，后面的节点可以告警、记录或重试它们，其余部分照常跑完。 来源：[n8n 文档：节点](https://docs.n8n.io/build/understand-workflows/workflow-components/work-with-nodes) (2026-11-04 查阅)；[n8n 文档：优雅地处理错误](https://docs.n8n.io/build/flow-logic/handle-errors-gracefully) (2026-11-04 查阅)；[n8n 仓库：编辑器字符串](https://github.com/n8n-io/n8n/blob/master/packages/frontend/@n8n/i18n/src/locales/en.json) (2026-11-04 查阅)；[n8n 仓库：执行引擎](https://github.com/n8n-io/n8n/blob/master/packages/core/src/execution-engine/workflow-execute.ts) (2026-11-04 查阅) ## 会改变失败后留下什么的工作流设置 [工作流设置](https://docs.n8n.io/build/manage-workflows/configure-workflow-settings)里有四项，决定失败之后你能看到什么。自托管时，它们在整个实例层面都有对应的环境变量，比如 `EXECUTIONS_DATA_SAVE_ON_ERROR` 和 `EXECUTIONS_TIMEOUT`。 超时是最容易被忘掉的一项。[执行变量页面](https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/use-environment-variables/executions)列出的 `EXECUTIONS_TIMEOUT` 默认值是 `-1`，表示关闭超时，所以卡住的执行会一直跑下去，没有处理器会知道。必须跑完的工作流，要打开 **Timeout Workflow**。 | 设置 | 文档怎么说 | | --- | --- | | Error workflow | 当前工作流失败时要触发的工作流 | | Save failed production executions | n8n 是否保存已发布工作流的失败执行 | | Save execution progress | 设为 Save 后，出错时工作流会从停下的地方继续，这可能增加延迟 | | Timeout Workflow | 过了设定的时间就取消这次执行，在 n8n Cloud 上，每个套餐有自己的最长时限 | ## 用 Stop And Error 主动失败 有些出问题的运行根本不会报错。接口返回 200 却是个空列表，或者你依赖的某个字段不存在。[Stop And Error](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.stopanderror) 把这种情况变成一次失败的执行，错误工作流就会触发。 它有两种操作。**Error Message** 多出一个字段，填要抛出的消息。**Error Object** 接收一个 JSON 对象，里面是你想抛出的错误属性。把这个节点放在 If 节点的 false 分支上，由 If 去检查你需要的那个条件。 ## 谁会收到通知 在付费套餐上，被设为错误工作流的那个工作流的运行[不计入](https://docs.n8n.io/build/understand-workflows/understand-executions)执行额度，所以处理器再啰嗦也不花额度。 n8n 2.5 在 2026 年 1 月 20 日发布，从这个版本起，如果实例里还没有错误工作流，工作流第一次在生产环境失败时，n8n 会给工作流的所有者发一封邮件。每个实例只发一次，所以它只是个提醒，算不上监控。想把事件送到自己的日志系统，内置的办法是[日志流](https://docs.n8n.io/administer/observe-and-log/stream-logs-to-external-systems)，它在 Cloud 和自托管上都是 Enterprise 功能。 > **漏掉失败的两种情况** > > 手动运行永远到不了 Error Trigger，设为 Continue 的节点则会让执行保持绿色。对重要的工作流，在 Continue 节点后面加一条分支，同时也要看 Executions 列表。 ## n8n 团队怎么说错误工作流和重试 2026 年 9 月 9 日，n8n 团队[在 X 上说](https://x.com/n8n_io/status/2097639369079181575)，错误工作流的运行现在在所有 n8n 套餐上都免费。Cloud 上已经生效，自托管从 2.38.0 版起生效。帖子的理由是，安全网不该和它保护的自动化抢额度。所以每个生产工作流，都应该指向你在这一课搭好的处理器。 更早一些，2026 年 6 月 18 日，团队在 X 上的[一条回复](https://x.com/n8n_io/status/2067568466161221784)讲了重试这件事。同样的要求再提一遍，得到的还是同样的答案。把确切的错误发回去，第二次尝试才有的放矢。 普通的 Retry On Fail 只是把同样的请求再发一次，适合服务一时繁忙或宕机的情况。对于要检查输出的步骤，比如 AI 节点，用 Continue (using error output) 接住失败，再把错误信息放进下一次尝试里。 > 错误工作流的运行，现在在所有 n8n 套餐上都免费。你的安全网，不该和它保护的自动化抢额度。 > > n8n.io, n8n 的官方账号，引文为译文, [X](https://x.com/n8n_io/status/2097639369079181575) (2026-11-05 查阅) [![n8n.io（@n8n_io）2026 年 9 月 9 日在 X 上的帖子：错误工作流的运行现在在所有 n8n 套餐上都免费。你的安全网，不该和它保护的自动化抢额度。设置一个错误工作流，在工作流失败时通知 Slack、邮件或你的工单工具。Cloud 上已经生效，自托管从 v2.38.0 起生效。](https://mindket.com/blog/shots/x-n8n-io-error-workflows-free.webp?v=894faee65ab8)](https://x.com/n8n_io/status/2097639369079181575) n8n.io 在 X 上，2026 年 9 月 9 日 [![n8n.io（@n8n_io）2026 年 6 月 18 日在 X 上一串帖子里的回复：说“再试一次”，得到的还是同样的答案。把确切的错误发回去，第二次尝试才有的放矢。](https://mindket.com/blog/shots/x-n8n-io-feed-back-the-error.webp?v=b102ccce4738)](https://x.com/n8n_io/status/2067568466161221784) n8n.io 在 X 上，2026 年 6 月 18 日 [n8n Advanced Course (5/8) - Error workflows](https://www.youtube.com/watch?v=77Ewdaby47M) n8n 自己的 YouTube 频道，Advanced Course 第 5 集，讲错误工作流。 > X 官方嵌入卡片的截图，拍摄于 2026 年 11 月 5 日，时间为 UTC。X 在第一条帖子处用“Show more”截断了后面的内容。点击截图可到 X 上打开原帖。 ## 常见错误 - 用 Execute workflow 来测试。处理器不理会手动运行，所以要发布被监控的工作流，让它的触发器自己触发。 - 忘了默认行为。包含 Error Trigger 节点的工作流，默认把自己当作错误工作流，所以处理器自己的 Error workflow 设置也要检查。 - 以为 `execution.url` 一定存在。触发器失败之后，数据里没有 `execution.id` 和 `execution.url`，细节在 `trigger` 里。 - 用了 Continue 就再也不看。执行显示成功，处理器保持沉默，下一个节点还可能跑在失败节点的输入数据上。更好的做法是选 Continue (using error output)，并处理那条分支。 - 什么都重试。重试对超时和限流有用，而错误的凭据或写错的表达式，每次尝试都会失败，默认就是三次。 - 没读 [n8n 3.0 的改动](https://docs.n8n.io/changelog/v30-breaking-changes)就给 If 或 Switch 节点打开 Always Output Data。在目前处于抢先体验阶段的 3.0 里，这个设置打开后，这类节点只在所有输出都为空时才加一个空数据项。2.x 里每个空输出都会得到一个，所以不该跑的分支也可能跑起来。 ## 自己试一试 - 按本课搭好处理器，把它接到一个以 Stop And Error 结尾的定时工作流上，在处理器的执行记录里看收到的数据。 - 给一个请求会返回错误的 HTTP Request 节点打开 Retry On Fail，把 Max. Tries 设成 2，把 Wait Between Tries (ms) 设成 2000，再和关掉重试时的运行时间比较。 - 把一个节点改成 Continue (using error output)，并把它的错误输出口接到 Slack 或 Send Email 节点。 - 打开一次失败的生产执行，选择 **Debug in editor**。[调试页面](https://docs.n8n.io/build/understand-workflows/understand-executions/debug-executions)说，n8n 会把数据复制到你的工作流里，并固定在第一个节点上。 ## 接下来学什么 [第 2 课](https://mindket.com/cn/learn/n8n-advanced/n8n-sub-workflows)把一个大工作流拆成子工作流，可以建一次，到处调用，告警步骤也能做成这样。想从现成的处理器开始，[导入 n8n 工作流](https://mindket.com/cn/blog/import-n8n-workflow)那篇讲了怎样把一个导入自己的实例，Mindket 的 n8n 工作流里也有现成的可选。 ## 自测一下 1. 错误工作流必须以哪个节点开头？ A. Stop And Error B. Error Trigger C. Execute Sub-workflow Trigger D. Webhook 答案：B。 文档说错误工作流必须以 Error Trigger 节点开头。 2. 你在一个会失败的工作流上点了 Execute workflow，它的错误工作流会收到什么？ A. 完整的错误数据 B. 只有失败节点的名称 C. 什么都收不到，因为 Error Trigger 只在自动执行时运行 答案：C。 Error Trigger 页面说，错误工作流不能用手动运行来测试。 3. 一个节点失败了，你想让失败的数据项走单独的分支，其余运行继续。该选哪个 On Error 设置？ A. Continue (using error output) B. Stop Workflow C. Continue 答案：A。 这个设置会为失败的数据项增加一个错误输出口，后面的节点继续运行。 4. Retry On Fail 适合处理哪种失败？ A. 错误的 API 密钥 B. 表达式里的拼写错误 C. 缺少一个输入字段 D. 自己会消失的超时 答案：D。 重试只是重跑同一个节点，所以只有原因在两次尝试之间消失时才有用。 ## 常见问题 ### 能用手动运行来测试 n8n 的错误工作流吗？ 不能。想随时看到处理器运行，就在被监控的工作流里放一个 Stop And Error 节点，发布它，再用一个每分钟触发一次的 Schedule Trigger 启动一次。试完记得取消发布。 ### 一个错误工作流能监控多个工作流吗？ 能。在每个工作流的设置里选同一个处理器即可。数据里带有 `workflow.id` 和 `workflow.name`，所以一个消息模板就能写出是哪个工作流失败了。 ### 错误工作流本身需要发布吗？ 不需要。Error Trigger 页面说，用了 Error Trigger 节点的工作流不需要发布。被它监控的工作流则需要发布，因为只有自动运行才会触发处理器。 ### 错误工作流的运行计入执行额度吗？ 不计入。在付费套餐上，只有生产执行才计入额度，文档把被设为错误工作流的那个工作流的运行，列在不计入的情况里。 ### Retry On Fail 和错误工作流有什么区别？ Retry On Fail 在同一次执行里重跑一个节点。错误工作流则是在整次执行失败之后，另外启动一个工作流。会自己恢复的失败用重试，需要人来处理的失败用处理器。 ### 失败执行的数据能找回到编辑器里吗？ 能。在 Executions 标签里选一次失败的执行，选择 Debug in editor，n8n 会把数据复制到你的工作流里，并固定在第一个节点上。文档里写明，Cloud 全部套餐可用，自托管则是已注册的 Community、Business 和 Enterprise。 ## 资料来源 - [n8n Docs: Handle errors gracefully](https://docs.n8n.io/build/flow-logic/handle-errors-gracefully) (2026-11-04 查阅) - [n8n Docs: Error Trigger node](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.errortrigger) (2026-11-04 查阅) - [n8n Docs: Stop And Error node](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.stopanderror) (2026-11-04 查阅) - [n8n Docs: Work with nodes](https://docs.n8n.io/build/understand-workflows/workflow-components/work-with-nodes) (2026-11-04 查阅) - [n8n Docs: Configure workflow settings](https://docs.n8n.io/build/manage-workflows/configure-workflow-settings) (2026-11-04 查阅) - [n8n Docs: Understand executions](https://docs.n8n.io/build/understand-workflows/understand-executions) (2026-11-04 查阅) - [n8n Docs: Debug executions](https://docs.n8n.io/build/understand-workflows/understand-executions/debug-executions) (2026-11-04 查阅) - [n8n Docs: Stream logs to external systems](https://docs.n8n.io/administer/observe-and-log/stream-logs-to-external-systems) (2026-11-04 查阅) - [n8n Docs: Executions environment variables](https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/use-environment-variables/executions) (2026-11-04 查阅) - [n8n Docs: v3.0 breaking changes](https://docs.n8n.io/changelog/v30-breaking-changes) (2026-11-05 查阅) - [n8n Docs: Release notes](https://docs.n8n.io/changelog/release-notes) (2026-11-04 查阅) - [n8n repository: execution engine (workflow-execute.ts)](https://github.com/n8n-io/n8n/blob/master/packages/core/src/execution-engine/workflow-execute.ts) (2026-11-04 查阅) - [n8n repository: editor strings (en.json)](https://github.com/n8n-io/n8n/blob/master/packages/frontend/@n8n/i18n/src/locales/en.json) (2026-11-04 查阅) - [n8n.io on X: error workflow runs are now free on every n8n plan, 9 September 2026](https://x.com/n8n_io/status/2097639369079181575) (2026-11-05 查阅) - [n8n.io on X: feed back the exact error, 18 June 2026](https://x.com/n8n_io/status/2067568466161221784) (2026-11-05 查阅) - [n8n on YouTube: n8n Advanced Course (5/8) - Error workflows](https://www.youtube.com/watch?v=77Ewdaby47M) (2026-11-05 查阅) [浏览 n8n 工作流](https://mindket.com/cn/automations/n8n)