You’ve deployed your webhook endpoint. The external service says it’s sending requests. But your logs show nothing. Here’s how to systematically debug incoming webhook issues.
The Debugging Checklist
Before diving deep, run through these quick checks:
| |
If your own curl request doesn’t reach the endpoint, the problem is infrastructure. If it does but the external service’s requests don’t arrive, the problem is somewhere in between.
Problem 1: The Endpoint Returns Success But Nothing Happens
Your webhook URL returns 200, but your application logic never runs.
Common cause: Multiple route handlers, and the wrong one is matching.
| |
Fix: Be explicit with your routes, or check the order of registration.
| |
Problem 2: Requests Arrive But Get Rejected
The service shows “delivered” but your server returns 4xx/5xx.
Debug by logging everything:
| |
Common causes:
- Missing required headers (signature verification failing)
- Body parsed as wrong content type
- Async function not awaited properly
Problem 3: Requests Never Arrive At All
The external service says “sent” but your server shows zero incoming requests.
Check 1: Is a proxy/load balancer eating requests?
| |
Check 2: Is a firewall blocking the source IP?
Many webhook providers publish their IP ranges. Make sure they’re allowed:
| |
Check 3: Is the webhook URL actually configured correctly?
This sounds obvious, but check for:
- HTTP vs HTTPS mismatch
- Trailing slash differences (
/webhookvs/webhook/) - URL encoding issues in the path
| |
Problem 4: Intermittent Failures
Sometimes requests arrive, sometimes they don’t.
Likely cause: Timeout issues. Your endpoint takes too long and the sender gives up.
| |
Most webhook senders expect a response within 5-30 seconds. If you can’t respond in time, they’ll retry—and you might process duplicates.
The Nuclear Option: Request Bin
When nothing else works, eliminate your infrastructure entirely:
- Go to webhook.site or requestbin.com
- Get a temporary URL
- Configure the external service to send to that URL
- Verify requests actually arrive
If requests arrive at the bin but not your server, the problem is definitely your infrastructure. If they don’t arrive at the bin either, the problem is on the sender’s side.
Quick Reference: Status Code Meanings
When debugging, know what the sender sees:
| Status | Sender’s Interpretation |
|---|---|
| 200-299 | Success, won’t retry |
| 400-499 | Your fault, may not retry |
| 500-599 | Their fault(?), will retry |
| Timeout | Will retry |
Pro tip: Always return 200 immediately, even if processing fails. Handle failures in a retry queue on your side rather than relying on the sender’s retry logic.
Checklist Summary
- ✅ Can you curl your own endpoint?
- ✅ Are logs showing any incoming requests?
- ✅ Check proxy/nginx/load balancer logs
- ✅ Verify firewall allows source IPs
- ✅ Confirm exact URL matches (http/https, trailing slash)
- ✅ Test with a request bin to isolate the problem
- ✅ Ensure response time is under timeout threshold
The webhook that silently fails is the worst kind of bug—no error message, no stack trace, just absence. Systematic elimination is the only way through.