What Is Webhook Monitoring?
Verifying that webhook events actually arrive and get processed, rather than trusting the sending provider's delivery dashboard.
Webhook monitoring is the practice of verifying that webhook events are actually arriving and being processed successfully, rather than assuming the sending provider's delivery log tells the whole story.
It exists because there are two separate systems involved and each only sees half the picture. The provider knows it sent a request and got a response code back. Your application knows what it did with the ones it received. Neither knows about the events that fell between.
Why a green endpoint proves less than it looks
The standard advice for webhook handlers is to respond quickly and do the work asynchronously. That advice is correct, and it also means your endpoint returns 200 before it knows whether the work will succeed.
A handler that accepts the request, enqueues a job, and returns 200 will report perfect delivery to the provider even if the queue worker has been dead for a week. From the provider's side the integration looks flawless.
Signature verification failures produce the same shape of problem. If a secret is rotated on one side only, every incoming event is rejected as unauthenticated, your endpoint is up, and the provider sees a consistent error code it will retry against and eventually abandon.
The four failure modes worth separating
| Failure mode | What the provider sees | What you see |
|---|---|---|
| Endpoint down | Connection errors, retries, then permanent failure | Nothing, unless something else alerts |
| Handler returns 200, work fails later | Successful delivery | Missing records, no error at the boundary |
| Signature or secret mismatch | Consistent 4xx, retries exhausted | Rejected events, often logged and ignored |
| Provider stops sending | Nothing to send, by its own logic | Silence that looks exactly like a quiet period |
The last row is the hardest. If a provider's integration is disconnected, a subscription lapses, or an event type is accidentally unsubscribed, no request is made, no error occurs anywhere, and every dashboard on both sides is clean.
How webhook monitoring is actually done
Three techniques cover most of it. The first is a heartbeat on the processing side: your handler pings a monitor after it finishes the work, so the monitor alerts when processing stops rather than when delivery stops.
The second is volume baselining. If you normally receive somewhere between 40 and 90 events an hour during business hours, zero events for three hours is a signal even though nothing errored.
The third is reconciliation, which is the only technique that catches everything. Periodically compare your records against the provider's API and alert on the difference. It is more work to build and it is the only method that does not depend on a webhook arriving to notice that webhooks stopped arriving.
Retries buy you time, not safety
Most major providers retry failed deliveries with exponential backoff over a window measured in hours or days, then stop permanently. That window is generous enough to survive a deploy and far too short to survive a long weekend.
Because retries mean the same event can arrive more than once, handlers must be idempotent. Processing the same payment notification twice is its own incident.
Related concepts
Start with what is a webhook for the underlying mechanism, and heartbeat monitoring for the check-in pattern described above. When events form an ordered sequence, see business flow monitoring.