How to monitor

How to monitor a webhook endpoint

Webhooks fail quietly — the receiver 500s, times out, or stops processing, and you lose events without noticing. Here's how to monitor webhook endpoints and delivery.

StatusCat2 min read

Webhooks are how a lot of systems talk to each other — payment events, CI notifications, form submissions, third-party callbacks. And they fail in an especially sneaky way: the sender thinks it delivered, your endpoint quietly 500s or times out, and events vanish. Nobody notices until something downstream is missing.

Here's how to monitor webhook endpoints properly — both "is it reachable" and "are events actually being processed."

Two layers to monitor

1. The receiving endpoint is up (HTTP check)

Point an HTTP check at your webhook URL (or a dedicated health route next to it). Because many webhook endpoints only accept POST, expose a small GET /webhooks/health alongside the receiver that confirms the app and its queue connection are healthy, and assert on a keyword like "status":"ok".

This catches a down app, a bad deploy, or a broken route.

2. Events are actually being processed (heartbeat)

An endpoint can return 200 while the queue behind it is stuck and nothing is being processed. To catch that, have your processing worker send a heartbeat while it's healthily consuming events:

# After a successful batch of webhook processing
curl -fsS -m 10 https://statuscat.co/ping/your-webhook-processor-id > /dev/null

Set the heartbeat interval to how often you expect to process events, with a sensible grace period. If deliveries stop or the processor stalls, the heartbeat stops arriving and StatusCat alerts you. (More on this pattern in how to monitor a cron job.)

Set it up in StatusCat

  1. Add an HTTP monitor on your webhook health endpoint with a keyword assertion.
  2. Add a heartbeat monitor and ping it from your processor after successful work.
  3. Set the interval and grace period to match your normal event volume.
  4. Wire alerts to Slack, email or SMS so a silent webhook failure reaches someone.

Don't forget

  • Verify signatures on inbound webhooks (security, not monitoring — but worth doing).
  • Return quickly. Accept the webhook, enqueue it, and process asynchronously — then monitor the queue with a heartbeat.
  • Monitor the SSL certificate on the webhook host; many providers refuse to deliver to an expired cert (SSL guide).

StatusCat supports HTTP and heartbeat monitors together, free for 50 monitors, so you can watch both the endpoint and the processing behind it. New to this? Start with what uptime monitoring is and how to monitor an API.

Frequently asked questions

How do I know if my webhook receiver is down?
Monitor the receiving endpoint directly with an HTTP check (and a keyword assertion), and add a heartbeat from your processing job so you also catch the case where the endpoint returns 200 but events aren't being processed.
What's the difference between the endpoint being up and events being processed?
An endpoint can return 200 while the queue behind it is stuck, so events pile up unprocessed. Checking the URL tells you it's reachable; a heartbeat from the processor tells you work is actually happening. You want both.
Can I get alerted if webhook volume drops to zero?
Yes, indirectly: have your processor send a heartbeat only while it's healthily consuming events. If deliveries stop (or the processor stalls), the heartbeat stops arriving within the expected window and StatusCat alerts you.

Keep reading

GuidesHow to monitor SSL certificate expiry (and never get caught out)Expired TLS certificates cause instant, total outages — and they're completely preventable. Here's how certificate expiry monitoring works and how to set it up in minutes.GuidesHow to monitor an API (the right way)A 200 response doesn't mean your API works. Here's how to monitor an API properly — status, latency, payload correctness, auth and SSL — so you catch real failures before your customers do.GuidesHow to monitor a cron job (with heartbeats)Cron jobs fail silently — the job stops, the server reboots, a deploy breaks the schedule, and nobody notices until data is missing. Here's how heartbeat monitoring catches it.