How long does Stripe retry failed webhooks?

Stripe retries for up to 3 days with exponential backoff (5 min, 1 hour, 6 hours, 12 hours, 24 hours, etc.). After 3 days, the event is permanently dropped. Sustained failures for several consecutive days will cause Stripe to disable the endpoint automatically.

What status code should my webhook endpoint return?

Any 2xx is treated as success. Use 200 OK with a small JSON body like {"received": true}. Avoid 204 No Content — while technically valid, some HTTP clients treat it oddly and it provides no body for keyword-based monitoring to verify.

Should I monitor every webhook endpoint or just the billing one?

Monitor every endpoint that processes critical state changes: billing, subscriptions, customer creation, payment intents, disputes. Each endpoint can fail independently. At minimum, set up dedicated monitoring for the endpoint receiving payment_intent.succeeded and invoice.paid events.

Can I monitor the webhook response time?

Yes — and you should. Stripe times out after 20 seconds, but performance degrades long before that. Set a FourSight latency alert at 5 seconds P95 to catch slowdowns before they become outages.

What's the difference between Stripe Dashboard delivery monitoring and external monitoring?

Stripe Dashboard shows what Stripe attempted to deliver and the response it got. External monitoring shows whether your endpoint is reachable and healthy from outside your infrastructure. You need both.

How do I handle webhook signature verification failures?

Always verify the Stripe-Signature header using your webhook secret before processing. If verification fails, return 400 — don't process. Log failures to your error tracker and alert on a sudden spike, which usually means your webhook secret was rotated without updating your code.

What if my webhook endpoint goes down during a deploy?

Stripe will retry the failed events for 3 days, so a short deploy gap usually has no permanent impact. Use a blue-green or rolling deploy strategy where the old version stays alive until the new version is healthy.

Should I expose my webhook endpoint publicly or behind auth?

Stripe webhooks must be publicly reachable. Security comes from signature verification (the Stripe-Signature header), not from network-level auth. Never put an API key check on a webhook endpoint.

Monitoring Stripe Webhook Reliability

Why Stripe Webhooks Fail Silently

Stripe webhooks are the nervous system of your billing infrastructure. When they fail, subscriptions don't activate, invoices don't process, plan upgrades don't apply, and customers get charged without receiving access. The worst part: these failures are often silent. There's no error page for the user to see, no support ticket triggered automatically, no obvious monitoring signal — just lost revenue, refund requests, and angry emails that arrive days later when the customer finally notices they paid for something they didn't get.

How the Stripe Webhook System Actually Works

Understanding Stripe's delivery model is the foundation of monitoring it correctly. Stripe sends webhook events as POST requests to your endpoint. Your endpoint must respond with a 2xx status code within 20 seconds. If you respond with any other status code, time out, or fail SSL handshake, Stripe marks the delivery as failed and retries with exponential backoff for up to 3 days. After 3 days of failures, the event is permanently dropped — and Stripe will disable the endpoint after sustained failures.

Retry Schedule

Stripe retries failed webhooks at increasing intervals: 5 minutes, 1 hour, 6 hours, 12 hours, 24 hours, and so on for 3 days. A short outage usually self-heals. A sustained outage of more than a few hours starts losing events permanently as the 3-day window closes.

Endpoint Disabling

If your endpoint fails for several consecutive days, Stripe automatically disables it. You'll get an email — easy to miss. Once disabled, no new events are sent, even if you fix the underlying issue. You must manually re-enable in the Stripe dashboard.

Idempotency

Because Stripe retries on failure, your handler MUST be idempotent. Processing the same event ID twice should produce the same result. This is a code-level concern, not a monitoring one — but it interacts with monitoring because retries are how delivery failures show up.

Common Webhook Failure Modes

Most webhook failures fall into a small number of predictable patterns. Knowing them lets you monitor each one specifically rather than hoping a generic uptime check catches everything.

Endpoint Timeouts

Stripe's 20-second budget sounds generous until you realize many webhook handlers run synchronous logic — provisioning accounts, sending emails, calling external APIs. Under load, p95 latency creeps up. Best practice: respond 200 immediately, queue the actual work asynchronously.

SSL Certificate Issues

An expired SSL cert on your webhook endpoint causes Stripe to reject the connection entirely. Self-signed or incomplete cert chains have the same effect. Monitor your webhook endpoint's SSL separately from the rest of your application — webhook domains are often forgotten when renewing certs.

Deployment Gaps

During deploys, your webhook endpoint may be briefly unavailable or returning 5xx from a half-deployed version. Stripe retries the failed events, but each retry consumes part of your 3-day window.

Signature Verification Failures

Stripe signs every webhook with your webhook secret. If you accidentally rotate the secret without updating your code, every event returns 400. You need to verify the response body, not just the status code.

Database Saturation

Webhook spikes during sales events can saturate your database. Your endpoint returns 500s, Stripe retries, retries pile up on the already-slow DB, cascade collapse. Monitor your webhook endpoint's response time, not just availability.

Setting Up Webhook Monitoring with FourSight

A basic HTTP 200 check is not enough for webhook monitoring. You need to verify the endpoint accepts and processes a valid Stripe-shaped request, returns the expected response body, and does it within the latency budget. Use FourSight's keyword monitor type to assert both status code AND response content.

💡 Always monitor your webhook endpoint separately from your main application. Webhook failures often occur independently — a worker queue might be backed up while your main site is perfectly healthy.

# Configure your webhook endpoint to return a consistent JSON body
# that you can verify with keyword monitoring.

POST /api/webhooks/stripe HTTP/1.1
Host: api.yourapp.com
Stripe-Signature: t=...,v1=...
Content-Type: application/json

{ "type": "ping", ... }

# Expected response:
HTTP/1.1 200 OK
{ "received": true, "version": "v3" }

# FourSight monitor configuration:
# - Type: HTTP keyword check
# - Method: POST with test ping payload
# - Required keyword: "received"
# - Interval: 30s (Growth+) or 60s (Starter)
# - Regions: at least US + EU
# - Alert threshold: 2 consecutive failures

Monitoring a Commercial SaaS?

FourSight includes 25 commercial-safe monitors with multi-region validation.

Start Monitoring Free

Detecting Silent Delivery Failures

Endpoint monitoring catches obvious failures, but not the trickier ones: Stripe disabled your endpoint, signature verification is rejecting valid events, or your handler is queueing events but the worker isn't processing them.

Heartbeat from Worker

Have your webhook worker emit a heartbeat ping to FourSight after each successfully processed event. If the heartbeat goes silent for more than your expected event interval, events are arriving but not being processed.

Cross-Reference with Stripe Dashboard

The Stripe Dashboard shows delivery success rate per endpoint. Set a weekly calendar reminder to check it — or use the Stripe API to pull endpoint delivery stats into your own monitoring dashboard.

Alerting for Webhook Failures

Webhook endpoint failures deserve the highest alert severity. A 30-minute outage during peak business hours can cost a mid-sized SaaS thousands of dollars in failed subscription activations and refund requests. Configure FourSight to page on-call immediately on webhook endpoint failures, bypass normal business-hours escalation, and route to your billing-team channel in addition to engineering.

Severity	Symptom	Response Time	Channel
Critical	Webhook 5xx > 2 minutes	Immediate page	PagerDuty + Slack + SMS
Major	P95 latency > 5s sustained	15 min	Slack + email
Minor	Single regional failure	1 hour	Slack channel only
Info	Single failed retry	Daily digest	Dashboard only

Testing Webhook Resilience

Don't wait for production to discover gaps. Regularly trigger test events from the Stripe Dashboard and verify the full pipeline: endpoint receives, signature verifies, handler runs, side effects complete. Add webhook resilience tests to your CI suite — a broken Stripe handler should fail builds, not production.

What to Do When You Lose Events

Even with perfect monitoring, you'll occasionally lose events to extended outages, deploy bugs, or third-party incidents on Stripe's side. Stripe provides the Events API to replay missed events — you can fetch all events of a given type since a timestamp and re-process them through your handler. Build this recovery script proactively, not during a crisis.