n8n 故障处理指南
让 n8n 工作流的失败可路由、可告警、可恢复。
内容明确要求错误响应脱敏、避免泄露堆栈/SQL/token，并提醒副作用测试前征得用户同意；但示例仍涉及日志、Slack、邮件、Data Table、n8n API 凭据和执行数据读取，未系统说明最小权限、敏感数据边界、回滚或数据保留，因此扣分。未发现明确红线风险。
两步错误输出配置、失败模式和回读校验说明较具体，静态上 happy path 可理解；但未执行，且存在响应节点 `respondWith: json` 与 `JSON.stringify` 是否双重编码的前后不一致，版本兼容性和异常输入覆盖也有限，故不超过静态上限并扣分。
触发条件、Webhook/无人值守/一次性工作流场景和若干非适用情形较清楚；但未定义完整输入输出契约、边界案例和语义误触发防护，未提供中文使用支持，也未证明 n8n-mcp、Slack/邮件等依赖在中国大陆网络环境中的可达性，因此扣分。
文档分层、目录、反模式、检查清单、安装前提、MIT 许可和 1.0.0 版本信息较完整；但缺少变更日志、明确维护责任人和更新路径，且对跨文件依赖和版本漂移的治理不足，因此扣分。
核心任务——配置错误输出、重试、API 状态码和 Error Workflow——给出了直接可复制的操作形状，理论上能完成主要工作；但没有静态可验证的代表性产出或运行结果，部分示例存在配置语义不确定性，仍需较多人工复核，按静态规则封顶为 7。
包含 JSON/JavaScript 示例、检查步骤和声称的权威事实来源类别，具有限定审计性；但未提供可核验的第三方证据、提交测试或 CI 覆盖，且本评估未执行任何复现，因此低于静态上限。
- 未执行 n8n 工作流或 MCP 操作；激活前应在隔离环境验证 `onError`、`main[1]`、重试上限和实际 HTTP 响应。
- 检查 `Respond to Webhook` 的 `respondWith` 与 `JSON.stringify` 组合，避免双重编码或版本相关行为。
- 不要默认把完整错误、执行输入或凭据相关字段发送到 Slack、邮件或外部日志；先确认权限、脱敏、保留期限和回退方案。
- 核心依赖 n8n-mcp 及可选通知服务；大陆网络可达性和替代通知通道需单独确认。
这个 Skill 能做什么，适合哪些场景？
这是 n8n-skills 仓库中的一个独立 Agent Skill，专注于 webhook、API 和无人值守工作流的故障处理。它指导用户配置节点级错误输出、网络重试、Error Trigger 工作流以及结构化的 4xx/5xx 响应。核心原则是同时设置 onError 和错误输出连接，避免错误被静默吞掉。它适合已使用 n8n-mcp 构建 n8n 工作流的用户；错误工作流的分配仍需在 n8n UI 中完成。
指导代理使用 n8n-mcp 配置节点的 onError、retryOnFail、maxTries 和 waitBetweenTries，使用 sourceIndex: 1 连接错误输出，构建 Error Trigger → 捕获 → 通知流程，并设计带有明确 HTTP 状态码和 {error,message} 结构的 Respond to Webhook 响应。它还指导代理通过 n8n_get_workflow 检查错误配置，并使用 validate_workflow、n8n_validate_workflow、n8n_autofix_workflow、n8n_test_workflow 和 n8n_executions 等工具进行验证、修复、测试和故障检查。
- 为需要 Respond to Webhook 的 API 或 webhook 工作流配置成功和失败响应的 n8n 开发者。
- 为 cron、队列或代理工具等无人值守工作流增加重试、告警和 Error Trigger 兜底的自动化工程师。
- 遇到工作流失败后静默结束、调用方超时或错误响应仍返回 200 的用户。
- 需要区分 400、401、403、404、429、500、502、503 和 504 原因，并返回结构化错误体的 API 构建者。
这个 Skill 有哪些优点和局限？
- 覆盖节点级错误输出、重试和工作流级兜底，形成完整故障处理链路。
- 明确指出 onError 与 main[1] 必须同时配置的常见静默失败陷阱。
- 提供按失败原因区分 4xx/5xx 的响应映射，并强调不要泄露内部错误信息。
- 包含可直接用于 n8n-mcp 操作的配置字段、连接方式和验证步骤。
- 只聚焦 n8n 错误处理，不负责完整的工作流架构、节点搜索或部署。
- Error Workflow 的分配无法通过社区 MCP 完成，必须在 n8n UI 中设置。
- 源材料没有提供该独立 Skill 在不同 n8n 版本、平台或真实项目中的测试结果。
- 重试会针对任何错误触发，且 maxTries 上限为 5、waitBetweenTries 上限为 5000 毫秒，无法按 HTTP 状态码筛选。
如何安装这个 Skill？
该 Skill 位于仓库的 skills/n8n-error-handling/SKILL.md。安装整个集合时，可在 Claude Code 中运行 /plugin install czlonkowski/n8n-skills；也可克隆仓库并将该技能文件夹复制到 Claude Code 技能目录：git clone https://github.com/czlonkowski/n8n-skills.git，然后复制 n8n-skills/skills/n8n-error-handling 到 ~/.claude/skills/。使用前还需要安装并配置 n8n-mcp MCP server。README 未提供只安装该技能的独立插件命令。
如何使用这个 Skill？
在已加载该 Skill 的环境中提出具体请求，例如："为我的 n8n webhook 工作流配置错误输出、重试和 4xx/5xx 响应"，或："我的 n8n 工作流失败后静默结束，请检查 onError 和 main[1] 连接"。对于无人值守工作流，还应要求创建 Error Trigger 工作流，并按指导在 n8n UI 的 Workflow Settings → Error Workflow 中分配它。
这个 Skill 与同类方案有什么区别？
相较于 n8n 默认的 stopWorkflow 行为，本 Skill 主张对面向外部调用者或无人值守的工作流显式路由、记录和恢复错误；它也区分节点级错误输出与工作流级 Error Trigger 兜底，两者分别处理已预见和未预见的失败。