简介

在任何生产工作流中,错误都会发生。API 返回 500、webhook 负载格式错误、数据库连接超时。问题不在于错误是否会发生——而在于你的工作流是优雅地处理它们,还是在静默中失手。

n8n 为你提供了两层错误处理机制:节点级别的本地错误处理,以及一个专门的 Error Trigger 节点,让你能够构建一个独立的工作流来专门捕获和响应故障。本课将同时涵盖这两层,重点聚焦于当故障发生时如何将真实的告警送到你手中。

n8n 默认如何处理节点故障

默认情况下,当节点抛出错误时,n8n 会停止该路径的执行,并将该次执行标记为失败。你会在执行历史中看到错误,但不会发生任何主动响应——没有告警、没有重试、没有回退。

对于每个节点,你都可以在该节点的设置面板中更改这一行为。三个最有用的选项是:

Stop workflow on error — 默认行为。执行在失败节点处终止。

Continue on error — 即便节点失败,n8n 也会继续向下传递执行。失败节点的输出项中会带有一个特殊字段来承载错误信息,你可以在下游进行检查。

Retry on fail — n8n 自动按可配置的次数重试该节点,每次重试之间带有延迟。这对于限流响应或网络抖动等瞬时故障非常有用。

要配置这些选项,请打开任意节点,进入 Settings(设置),找到 "On Error" 部分。对于重试,还需要将 "Retry On Fail" 设为 true,并以毫秒为单位定义 "Max Tries" 和 "Wait Between Tries"。

当你需要批量处理数据且不想让一条坏记录毁掉整次运行时,Continue on error 尤其强大。下游节点会收到如下形式的 item:

{
  "error": {
    "message": "Request failed with status code 404",
    "node": "HTTP Request",
    "stack": "..."
  }
}

然后你可以使用 IF 节点检查该 item 是否带有 error 字段,并将其路由到一个单独的分支进行记录或告警。

使用 Error Trigger 配置错误工作流

节点级设置处理的是单个节点的失败,但如果要捕获整个工作流中的任意故障,该怎么办?这正是 Error Trigger 节点的用途。

Error Trigger 在工作流级别工作。你需要创建一个独立的工作流(可以命名为 "Global Error Handler" 之类),并将其触发器设置为 Error Trigger。然后,在任何其他工作流中,进入 Settings 并将 "Error Workflow" 字段指向这个处理工作流。

当父工作流失败时,n8n 会自动启动错误处理工作流,并向其传递一个包含失败详情的 payload。payload 结构如下:

{
  "execution": {
    "id": "1042",
    "url": "https://your-n8n.com/execution/1042",
    "retryOf": null,
    "error": {
      "message": "Could not connect to the database",
      "stack": "Error: Could not connect..."
    },
    "lastNodeExecuted": "Postgres",
    "mode": "trigger"
  },
  "workflow": {
    "id": "88",
    "name": "Daily Invoice Sync"
  }
}

这为你提供了所需的全部信息:哪个工作流失败、最后执行的节点是哪一个、错误消息,以及执行日志的直接链接。

设置 Error Trigger 工作流的步骤:

1. 新建一个工作流,并将 Error Trigger 节点添加为起始节点。2. 添加所需的告警步骤——Slack、邮件、PagerDuty,或调用 webhook 的 HTTP Request 节点。3. 保存并发布该工作流。4. 在你的生产工作流中,打开 Settings,将 "Error Workflow" 设置为该处理工作流。

你可以设置一个全局错误处理器,并在实例中的每个工作流中重复使用它。

在出错时发送告警

在错误工作流中最常见的操作就是发送通知。下面是一个示例,利用 Error Trigger 中的数据向 Slack 频道发送消息:

// Inside a Slack node's message field (using an expression)
`Workflow "{{ $json.workflow.name }}" failed.
Node: {{ $json.execution.lastNodeExecuted }}
Error: {{ $json.execution.error.message }}
View execution: {{ $json.execution.url }}`

如果你更倾向于使用 HTTP Request 节点直接调用 Slack webhook:

{
  "text": "=Workflow \"{{ $json.workflow.name }}\" failed at node {{ $json.execution.lastNodeExecuted }}: {{ $json.execution.error.message }}"
}

对于通过 Send Email 节点发送邮件告警,只需将错误字段以同样的方式映射到主题和正文中。关键在于,Error Trigger payload 中的每个字段都可以通过常规的表达式语法来访问。

你也可以在告警步骤之前添加一个 Set 节点来重构或丰富数据——例如,根据工作流名称附加一个严重等级,或添加一个时间戳。

常见错误

将 Error Workflow 指向自身——如果你的错误处理工作流本身也出错了,n8n 不会再次递归触发它,但你会失去可见性。请保持错误处理工作流简洁且依赖轻量。

忘记发布错误处理器——被设为 Error Workflow 的工作流必须处于激活状态。如果它只是以草稿形式保存的,就不会执行。

到处使用 Continue on Error——这会掩盖真实的故障。将其留给那些你已有明确的下游逻辑来处理错误 item 的场景。不要把它当作一种回避不想处理的错误的手段。

没有测试错误路径——创建一个带有故意触发故障的测试工作流(例如一个指向返回 500 的 URL 的 HTTP Request 节点),并验证你的错误处理器确实被触发,以及发送的告警符合预期。

小结

节点级设置让你能够控制单个失败的行为:停止、继续或重试。Error Trigger 节点则让你能够构建一个集中式的处理器,在任何关联工作流失败时触发,为发送有意义的告警提供所需的执行上下文。将这两层结合起来,可以覆盖 n8n 中绝大多数的生产错误处理需求,且无需任何自定义代码。