Webhook Debugging: Capture and Inspect HTTP Callbacks
Webhooks are notoriously hard to debug. Here's how to capture, inspect, and replay webhook payloads for self-hosted applications.
Why Webhooks Are Hard to Debug
Webhooks are HTTP callbacks — a remote service sends a request to YOUR server when something happens. The problems:
1. You can't control when they fire
2. You can't see the request body without logging it
3. Failed webhooks often retry with backoff, flooding your logs
4. The sending service might not show you what it sent
Capturing Webhooks
Request Bin / Webhook.site
Public services that give you a temporary URL. Point your webhook there to see exactly what's being sent.
For self-hosted alternative: deploy Webhook.site on your own server.
Logging Middleware
Add middleware to your app that logs every incoming webhook:
ngrok / Cloudflare Tunnel
Expose your local development server to the internet so webhooks reach your machine.
Common Webhook Problems
Wrong URL
The webhook is configured to hit the wrong endpoint. Check the exact path.
Signature Verification Failing
Most webhooks include an HMAC signature. If verification fails:
Timeouts
Webhook senders expect a response within 5-30 seconds. If your handler does too much work synchronously, the sender times out and retries.
Solution: Return 200 immediately, process the webhook asynchronously.
Duplicate Events
Retries mean you might receive the same event multiple times. Make your webhook handler idempotent — processing the same event twice should be safe.
Webhook Best Practices
1. Always verify signatures
2. Return 200 quickly, process async
3. Log raw payloads for debugging
4. Implement idempotency (use event IDs)
5. Monitor for failed webhooks
6. Set up dead letter queues for permanently failed events
Self-Hosted Webhook Tools
Deploy any of these on TinyPod to add reliable webhook handling to your infrastructure.