你的 Webhook 处理程序会超时吗？
Slack 只等你的处理程序 3 秒，Shopify 等 5 秒，GitHub 等 10 秒。粘贴发送方投递的 URL，看看其中哪些会挂断。免费，无需注册。
我们会发送两个标记为测试的小 POST 请求，第二个紧跟在第一个之后，这样冷启动就会显现出来。如果这个 URL 会触发某些操作（一个 Zap、一封邮件），它会用测试数据运行。我们只保留主机名，不保留 URL。
每个发送方等多久
取自各平台的文档，核对于 2026-08-06。发送方没有及时收到 2xx，就会把这次投递算作失败，不管你的处理程序之后做了什么。
| 发送方 | 等待时长 | 投递失败之后 |
|---|---|---|
| LINE | 2 s | Webhook 重新投递，默认关闭（在频道的 Messaging API 设置中开启）；次数和间隔未公开 |
| Slack | 3 s | 重试 3 次：立即、1 分钟后、5 分钟后 |
| Discord | 3 s针对交互的首次响应；可以先延迟（type 5），之后再回复 | 未公布 |
| Xero | 5 s | 未公布 |
| Shopify | 5 s | 4 小时内重试 8 次 |
| Paddle | 5 s | 生产环境：约 2 天内最多尝试 60 次，第一个小时内约 10 次，第一天内约 45 次。沙盒：约 2 分钟内尝试 3 次 |
| HubSpot | 5 s | 最多尝试 10 次，分布在 24 小时内 |
| GitHub | 10 s | 无。GitHub 不会自动重新传递投递失败的 Webhook |
| Twilio | 15 s | 可配置：rc 取 0 到 5，默认 1。rp 指定哪些失败可以重试 |
处理程序为什么变慢了
现在大多数机器人和自动化流程都会在 Webhook 处理程序里调用大模型：总结消息、起草回复、给订单分类。这要花几秒，有时几十秒，而上面这些发送方不会等。常见的解决办法是先返回 200，再从后台队列里处理工作，而这意味着你得运行一个队列。
AnyHook 就是那个不用写代码的队列。它约 1 秒应答发送方，然后在 Free 套餐上给你的处理程序最多 60 秒，失败了还会重试。你只需改一个 URL，代码里别的地方都不用动。完整指南，附 Next.js、Workers、Express 和 Python 的代码。