痛点： n8n 的失败默认是静默的。token 过期了、API 变了，你要等到有人问「报告怎么不出了」才发现。而如果你曾经因为「就调了一个节点」把工作流搞崩过，那你就懂第二种痛：没有历史记录。

我搭的东西（一次导入，两个分支）：

  1. 告警： Error Trigger → Code（工作流名、出错节点、错误信息、执行记录直链、模式）→ Discord Webhook。如果你更想用邮件或 Telegram，把最后一个节点换掉即可。
  2. 备份： 每晚 02:00，调用 n8n API 的「获取全部工作流」接口 → 生成一个包含全部内容的 JSON 文件。

另外还提供一个 Python 脚本（只用标准库加 git），给想要真实历史记录的人用：backup 会为每个工作流导出一个文件，剔除易变字段让 diff 保持干净，然后提交并推送到你的私有仓库。check 会轮询失败的执行并告警到 Discord 或邮件（第一次运行只是把旧的失败记录记下来）。

结果 / 我的测试方式（在真实的本地 n8n 2.43 上）：

  • 一个故意失败的生产工作流触发了错误工作流，Discord 消息里带上了名称、节点、消息和链接。
  • 夜间分支把全部 16 个工作流写进了同一个文件，里面不含任何 API 密钥或凭据机密。
  • Python 备份已提交并推送到测试远端。重命名一个工作流只产生单文件差异，未发生改动的运行不会产生提交。

我踩过的坑，你们就不用再踩了：

  • 错误工作流必须处于 Active 状态（否则 n8n 会记录「is not active and cannot be executed」），并且每个工作流都必须在 Settings → Error workflow 下选中它。
  • 手动测试运行不会触发它，只有生产执行才会触发。
  • n8n 2.x 只会把文件写入 ~/.n8n-files 内部，不会创建子文件夹，而且该文件夹必须事先存在。
  • 备份分支需要先配好 n8n 的 API 凭证，n8n 才会允许你激活工作流。

实话说的局限： 凭证不在备份里（恢复后要重新填）。这套只在自托管环境测过，没在 n8n Cloud 上测过。

工作流 + 脚本（MIT 许可）：https://github.com/salamc/tasktoagent-free-agents/tree/main/n8n-error-alert-and-backup

先说明一下：我自己在运营 TaskToAgent（tasktoagent.com），免费、不用注册。测这个的时候我发现，我们自己早先的模板里有个「Remove Duplicates」设置写错了（removeItemsRepeatedInPreviousExecutions 并不是真实存在的操作，应该写成 removeItemsSeenInPreviousExecutions），已经改过来了——这也正是我想给所有环节都加上告警的原因。