这是什么
一个免费的 Webhook 投递失败分诊台。它读取普通日志，并整理成清晰的案件、原因和下一步清单。
Webhook 故障分诊
每一个失败的 Webhook 都值得一次尸检。
粘贴来自 Stripe、GitHub、Shopify 或你自己队列的投递日志。Webhook Morgue 会为每次失败标注原因，告诉你哪些可以安全重放，并按合理的等待时间生成重放计划。
适合谁
接收支付、电商或代码平台 Webhook 的开发者和值班工程师，需要快速决定哪些该重试。
解决什么
盲目重试。重放 401 或 410 只会制造更多失败，而 500 或超时通常只需要从容地再试一次。这个工具帮你分清两者。
案卷
每行一次投递。用竖线分隔事件、状态码和备注，或直接粘贴 JSON 行。
示例行：invoice.paid | 500 | upstream timeout | 14:02
暂无案件
载入演示日志，查看八次投递的完整尸检；或者粘贴你自己的日志。
日志只在你的浏览器中读取，不会上传任何内容。
签名校验
大多数 401 错误源于签名不匹配。粘贴原始请求体、签名密钥和签名请求头，看看它们是否一致。
请使用测试密钥。校验在浏览器中完成，密钥不会离开本页。
HMAC SHA 256 由浏览器中的 Web Crypto API 计算。
死因一览
每种失败通常意味着什么，以及该怎么处理。
超时
按退避策略重放。让处理程序在几秒内响应，把耗时工作放进队列。
接收端崩溃
等接收端恢复后按退避策略重放。查看它针对这个事件的错误日志。
触发限流
按接收端要求的时间等待，然后放慢速度重放。
签名或鉴权被拒
先别重放。核对双方的签名密钥，然后只重放一次。
端点已不存在
不要重放。把 Webhook 指向新的端点，或者取消订阅。
内容被拒
不要原样重放。先修复处理程序或数据结构，再重放一次。
被重定向
接收端不应该重定向。把 Webhook 地址改成最终地址。
已送达
无需处理，这次投递已经送达。
使用方法
导出日志
从服务商后台或你自己的队列复制失败的投递。有事件名和状态码就够了。
开始尸检
每一行都会变成带标签的案件，附上死因和明确的下一步。
按计划执行
按建议的时间表重放安全的案件，其余的先修复，再把报告分享给团队。
它不做什么
- 它不会连接你的服务商，也不会替你重放。它只告诉你该重放什么、何时重放。
- 它看不到接收端内部。500 说明你的代码出错了，但仅凭日志无法知道原因。
- 它只读取这里展示的格式。特殊的日志可能需要先简单整理。
常见问题
我的日志会被发送到别处吗？
不会。解析、计划和签名校验全部在你的浏览器中运行。
为什么不全部重放？
重放 401、404 或 422 会以同样的方式再次失败，还可能触发告警或封禁。先修复原因，再重放一次。
为什么等待时间不均匀？
一点随机偏移，也就是抖动，可以避免大量重试在同一秒冲击正在恢复的服务器。