n8n故障告警只发送最小定位信息

n8n 的 AI 工作流失败后，错误载荷可能带着请求或响应细节。把它直接发到 Slack 或邮件，排障通知就可能变成数据外发通道。作者给出的办法很克制：告警只保留工作流标签、失败阶段和可选的执行 ID。

这套方案值得看的是字段如何筛选，以及怎样验证告警链路。不过，作者只用合成输入检查了 JavaScript，尚未验证真实 n8n 工作流的消息投递，落地前还需要补上这一环。

为什么告警只需要三个字段

告警的第一份工作，是告诉接收者去哪里调查。作者认为，工作流标签、失败阶段和执行 ID 已足够启动排查，请求内容、响应内容和堆栈不必随通知一起发送。

具体配置是保存一条 Error Trigger → Code → Slack or Email 错误工作流，再到 AI 工作流的设置中，通过 Error workflow 选择它。同一条错误工作流可以分配给多个工作流。

这里采用的是允许名单：从批准过的字段构造新对象。相比先复制错误载荷、再删除敏感字段，它更容易检查，也不会因为漏删某个字段就把该字段带出去。

工作流名称同样需要控制。作者用预先批准的标签映射替代直接发送原始名称；接收端能看到什么，由映射表决定。

三个字段怎样生成，才能避免误判

把 Code 节点设为 JavaScript，执行模式选择 Run Once for All Items。下面这段代码负责生成告警对象，其中合成工作流 ID 42 和标签 support-triage 要替换成经过批准的值。

const event = $input.first().json;
const workflowLabels = new Map([["42", "support-triage"]]);
const workflow = workflowLabels.get(String(event.workflow?.id ?? "")) ?? "unmapped";
const phase = event.trigger ? "trigger" : event.execution ? "execution" : "unknown";
const alert = { workflow, phase };

const rawId = event.execution?.id;
const id = typeof rawId === "string" ? rawId : Number.isSafeInteger(rawId) ? String(rawId) : "";
if (/^[0-9]{1,20}$/.test(id)) {
  alert.executionId = id;
}

return [{ json: alert }];

重点看 phase 的判断：它读取事件里的 trigger 和 execution，没有用执行 ID 是否存在来推断阶段。原因是未保存的执行也可能没有 ID，缺少 ID 并不能证明故障发生在触发器。

执行 ID 则经过两步筛选：字符串直接进入格式检查，安全整数先转成字符串；最后只有匹配 /^[0-9]{1,20}$/，即 1 至 20 位数字的值，才写入 executionId。不符合条件就省略，不把原始值塞进消息。

下游发送节点也要遵守同一边界，只使用 workflow、phase 和存在时的 executionId。例如，已保存的执行失败可以发出 support-triage · execution · 231，触发阶段失败可以发出 support-triage · trigger。未匹配到标签时使用 unmapped，阶段无法识别时使用 unknown。

只在 Code 节点筛选字段还不够，最终消息模板也必须只引用批准字段。

为什么编辑器里点执行，不算验证通过

作者建议在 staging 环境搭建一条 Webhook → Stop And Error 工作流，Webhook 使用身份认证，错误消息固定为无害的合成内容 ALERT_TEST_ONLY。为它指定错误工作流，并把告警目的地设为测试频道。

测试顺序是：发布 staging 工作流，调用一次 Webhook 的 Production URL，然后取消发布。这里的 Production URL 是 Webhook 的地址类型，测试工作流仍放在 staging 环境。

不能用编辑器里的 Execute workflow 替代这一步。按原文说明，Error Trigger 响应自动执行产生的失败，手动执行无法覆盖这条触发链路。

验收要同时检查两件事：通知是否带着预期标签和阶段到达，以及错误消息、堆栈、执行 URL 是否确实没有出现。执行数据由谁访问、保留多久，需要另行检查，告警字段收缩并没有解决这些问题。

作者明确说，JavaScript 只经过合成输入检查，真实 n8n 工作流投递尚未测试。因此，这是一份可供验证的实现方案，不能当作已经跑通的端到端结果。

我的判断

我认可从允许名单构建告警的方向。它把审查范围压缩到一个小对象和一份消息模板，比维护一串「不能发送什么」的删除规则更直观。

代价是通知里的上下文更少。与直接附上堆栈或执行 URL 相比，接收者需要进入 n8n 继续调查；如果标签是 unmapped，又缺少执行 ID，定位线索还会进一步减少。因此，标签映射需要维护，调查人员也需要具备适当的执行数据访问权限。

「三个字段足够启动调查」是作者的经验判断，原文没有给出排障耗时或泄露风险的对照数据。它适合作为告警最小化的起点，是否够用，仍要结合团队实际排查过程验证。

能拿来做什么

• 给现有 n8n AI 工作流配置共用错误工作流，并为每个来源维护经过批准的标签，避免把原始错误载荷直接发到 Slack 或邮件。
• 检查发送节点的消息表达式，确保只引用 workflow、phase 和可选的 executionId，尤其确认没有附带错误消息、堆栈或执行 URL。
• 在 staging 按 ALERT_TEST_ONLY 流程完成一次自动失败测试，同时核对通知送达和字段缺失情况，再单独审查执行数据的访问权限与保留时间。