你的 Webhook 處理程式會逾時嗎？
Slack 等處理程式回應 3 秒，Shopify 等 5 秒，GitHub 等 10 秒。貼上發送端 POST 的網址，看看哪幾家會掛斷。免費，不用註冊。
我們會送出兩個標示為測試的小型 POST 請求，第二個緊接在第一個之後，這樣冷啟動才看得出來。如果這個網址會觸發什麼（一個 Zap、一封信），它會用測試資料執行。我們保存主機名稱，不保存網址。
每個發送端等多久
取自各服務商的文件，檢查於 2026-08-06。發送端沒有及時收到 2xx，就會把這次傳遞算成失敗，不管你的處理程式之後做了什麼。
| 發送端 | 等待時間 | 傳遞失敗後 |
|---|---|---|
| LINE | 2 s | Webhook redelivery（Webhook 重新傳送），預設關閉（在頻道的 Messaging API 設定中開啟）；次數與間隔未公開 |
| Slack | 3 s | 重試 3 次：立即、1 分鐘後、5 分鐘後 |
| Discord | 3 s指 interaction 的第一個回應；可以延後（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 不會自動重新傳送 |
| Twilio | 15 s | 可設定：rc 為 0 到 5，預設 1。rp 決定哪些失敗會重試 |
處理程式為什麼變慢
現在大多數的機器人和自動化流程，都會在 Webhook 處理程式裡呼叫 LLM：摘要訊息、草擬回覆、分類訂單。這要花好幾秒，有時好幾十秒，而上面這些發送端不會等。常見的解法是先回 200，再從背景佇列處理工作，而這代表你得自己維運一個佇列。
AnyHook 就是那個佇列，而且不用寫程式。它大約 1 秒就回應發送端，再給你的處理程式最多 60 秒（Free 方案），失敗會重試。你只要換一個網址，程式碼其他地方都不用動。完整指南，附 Next.js、Workers、Express 與 Python 的程式碼。