Webhook Monitoring: How to Know When Stripe (or Any Integration) Stops Working

December 21, 2025

Your uptime dashboard can be 100% green while your business is silently broken.

It happens when a critical event flow stops:

Stripe webhooks stop arriving, so payments don’t activate accounts
Shopify order events fail, so fulfillment never starts
Zapier/Make automations stop, so leads stop routing
Email provider callbacks fail, so password resets never land

The site is “up”… but the system is down.

This guide shows a practical way to monitor webhook-based workflows using a simple pattern: heartbeat monitoring. If expected events don’t arrive on time, you get alerted.

What Is Webhook Monitoring?

Webhook monitoring is making sure two things stay true:

Your webhook endpoint is reachable (the URL responds correctly).
Your webhook flow is alive (real events are actually arriving and being processed).

Most teams only do #1 (a basic HTTP check). The “silent failures” usually happen in #2.

Common webhook failure modes (that feel invisible)

Signature verification breaks (secret rotated, tolerance changed, code bug).
Queue/worker backlog (endpoint returns 200, but the work that applies the event is stuck).
Provider retries/pauses (repeated 5xx responses, misconfigured endpoint, rate limits).
Networking/DNS issues (WAF rules, routing changes, region failures).

The Simple Strategy: Monitor Reachability + Monitor Flow

Step 1) Monitor the webhook endpoint (reachability)

Create a basic website/HTTP monitor for your webhook URL, for example:

https://api.yourapp.com/webhooks/stripe

This catches the obvious stuff: DNS failures, TLS issues, 5xx spikes, and timeouts.

If you want the classic “is this URL up?” coverage, this is exactly what Website Monitoring is for.

Step 2) Monitor webhook flow with a heartbeat (liveness)

Now the important part: set up a heartbeat monitor that expects check-ins.

Idea: every time you receive a “business critical” webhook event, ping a unique heartbeat URL. If the heartbeat doesn’t get pinged within the expected window, alert.

In UpDog terms, this maps cleanly to Cron Job Monitoring (Heartbeat Monitoring): you create a monitor, get a unique URL, and your job (or webhook handler) “checks in.” If it stops checking in, you get notified.

Which events should ping the heartbeat?

Pick one or two events that represent “money is flowing” or “core workflow is healthy.” Examples:

Stripe: checkout.session.completed or invoice.paid
Auth: new user created / email verified
Leads: form submit / inbound lead webhook
Background processing: “job completed” signals

Implementation: Ping a Heartbeat URL When Events Arrive

You’ll do this in your webhook handler after you’ve verified the request and accepted the event.

Important: don’t block your webhook response waiting on the heartbeat ping. Providers care that you respond quickly. Treat the heartbeat ping as best-effort.

Node.js (Express) example

// after verifying the webhook signature and parsing the event:
const HEARTBEAT_URL = process.env.WEBHOOK_HEARTBEAT_URL;

function pingHeartbeat() {
  if (!HEARTBEAT_URL) return;
  try {
    fetch(HEARTBEAT_URL, { method: "GET" }).catch(() => {});
  } catch (e) {}
}

// Only ping on “money happened” signals
if (event.type === "checkout.session.completed" || event.type === "invoice.paid") {
  pingHeartbeat();
}

Python (Django) example

import os
import requests

HEARTBEAT_URL = os.getenv("WEBHOOK_HEARTBEAT_URL")

def ping_heartbeat():
    if not HEARTBEAT_URL:
        return
    try:
        requests.get(HEARTBEAT_URL, timeout=1.5)
    except Exception:
        pass

# In your webhook view, after verification:
if event_type in ("checkout.session.completed", "invoice.paid"):
    ping_heartbeat()

PHP (Laravel) example

use Illuminate\Support\Facades\Http;

$heartbeatUrl = env('WEBHOOK_HEARTBEAT_URL');

function pingHeartbeat($url) {
  if (!$url) return;
  try {
    Http::timeout(1.5)->get($url);
  } catch (\Throwable $e) {
    // swallow errors
  }
}

if (in_array($eventType, ['checkout.session.completed', 'invoice.paid'])) {
  pingHeartbeat($heartbeatUrl);
}

How to Choose the “Expected Window” (Without False Alarms)

Set the heartbeat expectation to match how your business actually behaves.

Pattern A: “We should see at least one per day”

If you have daily payments/signups, expect at least one heartbeat per 24 hours (+ grace). If a full day goes by with no paid events, that’s either a growth signal or an integration outage worth knowing about.

Pattern B: “We should see one per hour during business hours”

If volume is steady, alert fast during the hours you care about, and stay quiet overnight.

Pattern C: Two heartbeats for better debugging

Heartbeat 1: Webhook received (provider → your endpoint)
Heartbeat 2: Webhook applied (your worker finished processing)

This helps you distinguish “provider can’t reach us” from “we’re receiving events but not processing them.”

Bonus: Catch “Up But Broken” States

Some failures don’t show up as 5xx errors. You might return 200 but render an error screen, maintenance banner, or missing UI.

That’s where Keyword Monitoring shines: verify the page content, not just the status code.

Monitor for a login form element or “Welcome back” text
Alert if an “Exception”, “Error”, or “Maintenance” banner appears
Verify a JSON health endpoint still contains "status":"ok"

Bonus: If Your Webhook Endpoint Gets Slow, Treat It Like an Incident

Many webhook providers will retry or mark delivery unhealthy if your endpoint is consistently slow.

Use Response Time Monitoring & Latency Alerts to catch regressions early — because “slow feels down,” especially for integrations.

What to Put on Your Status Page

If a webhook pipeline is business-critical, it’s worth exposing as a user-facing component (even if you keep details vague):

Billing / Payments
Email delivery
Background processing
Integrations

That’s exactly the job of Branded Status Pages: turn “is it just me?” into a clear answer and fewer support tickets.

Quick Checklist

✅ Monitor webhook endpoint reachability (HTTP)
✅ Monitor webhook flow with a heartbeat (expected check-ins)
✅ Optional second heartbeat for “event applied”
✅ Add keyword checks for “up but broken” pages
✅ Track response time so slowdowns don’t become outages

Wrap-up

Traditional uptime checks answer: “Does the URL respond?”

Webhook monitoring answers the more expensive question: “Is the business working?”

If you want a simple way to set up external uptime checks, heartbeat monitors, alerting, and a clean status page without managing extra servers, you can start in UpDog here:

Start Monitoring for Free

Get a WatchDog for your site.

Start Monitoring For Free with UpDog