How to Monitor Webhooks for Uptime and Reliability

Webhooks are one of the most overlooked components when it comes to uptime monitoring. They're passive by nature — they sit quietly, waiting for events to arrive — which means when they break, nothing immediately complains. Data stops flowing, integrations silently fail, and you may not notice for hours or days.

Webhook monitoring is the practice of ensuring your webhook receiver endpoints are accessible, responding correctly, and actually processing incoming events.

Why Webhook Monitoring Matters

Consider the consequences of a broken webhook endpoint:

• Stripe webhooks stop processing → subscription events (payment failures, cancellations) are missed
• GitHub webhooks fail → your CI/CD pipeline stops triggering on code pushes
• Shopify webhooks break → order notifications stop arriving in your system
• Slack webhooks go down → your application's notifications stop reaching your team

Unlike a broken web page that users actively report, broken webhooks fail silently. The sender typically retries a few times, then gives up. You lose data and you don't know it.

Two Types of Webhook Monitoring

1. Endpoint Availability Monitoring

Confirms your webhook receiver URL is accessible and returning the expected status code. This is standard HTTP uptime monitoring applied to a webhook endpoint.

A webhook receiver typically responds to GET requests with a 200 or 404 (since webhook data arrives via POST). More useful: confirm the endpoint responds to a POST request.

Configure your uptime monitor to:

• Send a POST request to your webhook URL
• Include minimal valid JSON in the body: {}
• Check for a 200 OK response (or whatever your receiver returns for an empty/test payload)

This confirms the endpoint is reachable and your web server is routing the request correctly.

2. Webhook Delivery Monitoring

Confirms that webhook events from the sender (Stripe, GitHub, etc.) are actually arriving and being processed. This requires a different approach — you need to check that recent events have been received.

Options for delivery monitoring:

• Monitor your webhook processing logs — check that entries appear at expected intervals
• Use heartbeat monitoring — have your webhook handler ping a heartbeat monitor each time it processes an event
• Check your database — monitor the last-processed timestamp of webhook events in your database
• Use the sender's webhook dashboard — most webhook providers (Stripe, GitHub, Twilio) have dashboards showing delivery success rates

Setting Up Endpoint Availability Monitoring

Your webhook receiver endpoint is just an HTTP endpoint — treat it like any other API endpoint for availability monitoring:

Monitor: https://yourdomain.com/webhooks/stripe
Method: POST
Body: {}
Expected status: 200 (or 400 if your receiver validates signatures)
Interval: 5 minutes

Note on signature validation: many webhook receivers validate a signature header before processing. If yours does, a POST from your monitor without a valid signature may return 400 or 401. You can:

1. Configure your monitor to accept 400 as a "passing" status (the endpoint is reachable and responding)
2. Add a GET /webhooks/health endpoint that returns 200 without requiring a signature
3. Generate a valid test signature in your monitor's custom headers

Monitoring Webhooks from Different Providers

Stripe

Stripe provides a webhook log in the dashboard showing delivery attempts and success/failure status. Monitor your Stripe webhook endpoint's uptime AND regularly check the Stripe dashboard for failed deliveries.

For your Stripe webhook receiver, monitor the endpoint URL you configured in the Stripe dashboard.

GitHub / GitLab

Webhook delivery history is visible in your repository settings. Monitor the endpoint your CI/CD pipeline or integration tool uses. A failed GitHub webhook means deployments stop triggering automatically.

Twilio

Twilio sends webhooks for incoming SMS and calls. Monitor your Twilio callback URL. A broken Twilio webhook means inbound messages and calls aren't handled by your application.

Heartbeat Pattern for Webhook Processing

For critical webhooks where you must know data is being processed (not just that the endpoint is reachable), use the heartbeat pattern:

// In your webhook handler
app.post('/webhooks/stripe', async (req, res) => {
  // Process the webhook...
  await processStripeEvent(req.body);

  // Ping heartbeat monitor
  await fetch(process.env.STRIPE_HEARTBEAT_URL);

  res.sendStatus(200);
});

If Stripe stops sending events (or your processing breaks), the heartbeat stops arriving and you get an alert. If your endpoint is down, you also get an uptime alert.

This two-layer approach catches both endpoint availability failures and data processing failures.

Alert Configuration for Webhook Monitoring

Webhook failures can have high business impact. Configure alerts with appropriate urgency:

• Payment webhooks (Stripe, PayPal) — SMS + Slack immediately
• CI/CD webhooks (GitHub, GitLab) — Slack for development team
• Notification webhooks (Slack incoming) — lower priority; email alert

Testing Your Webhook Endpoint

Before adding monitoring, verify your endpoint is working correctly:

1. Use the sender's test feature (Stripe has "Send test webhook", GitHub has "Redeliver" in webhook settings)
2. Use a tool like curl to POST test data to your endpoint
3. Check your application logs to confirm the test event was processed

Once you know the endpoint works manually, your monitoring setup provides ongoing verification.

Domain Monitor can monitor your webhook endpoints alongside your websites, APIs, and SSL certificates — giving you a single dashboard for your complete web infrastructure.

Monitor your webhook endpoints at Domain Monitor.

Related Articles

• "How to Monitor Laravel Applications for Uptime and Health"
• "How to Monitor Ruby on Rails Applications for Uptime"
• "How to Monitor Vue.js Applications for Uptime and Availability"