Webhook Monitoring for SaaS Companies
Under-provisioning generates support tickets. Over-provisioning generates nothing at all, which is why it runs for months.
In a subscription business, billing webhooks control access. When one goes missing, your entitlement state and your billing state disagree, and the direction of the disagreement determines whether you ever find out.
The asymmetry that matters
If a customer pays and the upgrade webhook is missed, they contact support within the hour. Annoying, visible, quickly fixed.
If a customer cancels and the cancellation webhook is missed, they keep full access to a product they have stopped paying for. Nobody files a ticket about getting something for free. That failure runs until somebody audits, and audits are rare.
Same bug, same root cause, wildly different discovery time. This is why SaaS teams consistently underestimate how long their entitlement drift has been running.
| Missed event | Effect | Time to discovery |
|---|---|---|
| subscription.updated (upgrade) | Customer paid, no new features | Under an hour |
| subscription.deleted | Cancelled customer keeps access | Months, or never |
| invoice.payment_failed | Dunning never starts, churn is silent | At renewal, as a surprise |
| subscription.trial_will_end | No conversion nudge sent | Never, as lower conversion |
| invoice.paid | Account stays restricted after payment | Minutes |
Audit entitlements rather than trusting events
The durable fix is not better webhook handling. It is a scheduled job that compares what your billing provider thinks each customer is entitled to against what your application grants them, and alerts on every mismatch.
Run it nightly. The first run on an established product almost always finds something, and the number it finds is a reasonable estimate of what the last year cost you.
Dunning is a sequence, not an event
A failed payment starts a process: retry, notify the customer, retry again, eventually restrict or cancel. Each step is a separate webhook and each one can be missed independently.
A dunning sequence that stalls at step two produces a customer who was never told their card failed and is now quietly on their way to churning. Nothing errored, and your failed-payment dashboard shows the failure was received.
This is a sequence worth tracking per customer rather than in aggregate, which is what business flow monitoring describes.
Your own outbound webhooks
If your product sends webhooks to customers, you are on the other side of everything on this page. Your customers will build integrations that depend on your delivery, and they will notice when it stops.
Three things make that relationship survivable: a visible delivery log so customers can self-diagnose, a manual redelivery control so support can resolve a complaint without engineering, and an alert when your own delivery success rate drops rather than waiting for the first complaint.
Signing with HMAC-SHA256 over the raw body plus a timestamp is the convention your customers will expect, because it is what Stripe, GitHub and Shopify all do.
Where to start
Add the nightly entitlement audit before adding any monitoring. It tells you the size of the problem you have, and it keeps working regardless of which webhooks break next.
Then monitor billing webhook ingestion for the gap that means events have stopped arriving entirely. SensaCat covers that, along with the credential expiries that break billing integrations without warning. Start free.