--- title: "Monitoring Stripe Webhook Reliability | FourSight" description: "Ensure payment events never silently fail. Learn how to verify webhook delivery, retry logic, and alerting." lang: en json-ld: | [ { "@context": "https://schema.org", "@type": "Article", "headline": "Monitoring Stripe Webhook Reliability", "description": "Ensure payment events never silently fail. Learn how to verify webhook delivery, retry logic, and alerting.", "author": { "@type": "Organization", "name": "FourSight" }, "publisher": { "@type": "Organization", "name": "FourSight" }, "url": "https://foursight.cloud/guides/monitoring-stripe-webhooks", "mainEntityOfPage": "https://foursight.cloud/guides/monitoring-stripe-webhooks", "datePublished": "2025-03-05", "dateModified": "2025-11-07", "wordCount": 2200 }, { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://foursight.cloud" }, { "@type": "ListItem", "position": 2, "name": "Guides", "item": "https://foursight.cloud/guides" }, { "@type": "ListItem", "position": 3, "name": "Monitoring Stripe Webhook Reliability", "item": "https://foursight.cloud/guides/monitoring-stripe-webhooks" } ] }, { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "How long does Stripe retry failed webhooks?", "acceptedAnswer": { "@type": "Answer", "text": "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." } }, { "@type": "Question", "name": "What status code should my webhook endpoint return?", "acceptedAnswer": { "@type": "Answer", "text": "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." } }, { "@type": "Question", "name": "Should I monitor every webhook endpoint or just the billing one?", "acceptedAnswer": { "@type": "Answer", "text": "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." } }, { "@type": "Question", "name": "Can I monitor the webhook response time?", "acceptedAnswer": { "@type": "Answer", "text": "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." } }, { "@type": "Question", "name": "What's the difference between Stripe Dashboard delivery monitoring and external monitoring?", "acceptedAnswer": { "@type": "Answer", "text": "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." } }, { "@type": "Question", "name": "How do I handle webhook signature verification failures?", "acceptedAnswer": { "@type": "Answer", "text": "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." } }, { "@type": "Question", "name": "What if my webhook endpoint goes down during a deploy?", "acceptedAnswer": { "@type": "Answer", "text": "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." } }, { "@type": "Question", "name": "Should I expose my webhook endpoint publicly or behind auth?", "acceptedAnswer": { "@type": "Answer", "text": "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." } } ] } ] --- [FourSight ](/) [Features](/#features)[Pricing](/pricing)[Guides](/guides)[Glossary](/glossary)[FAQ](/faq) [Login](/auth)[Start free](/auth?signup=true) [Start free](/auth?signup=true) [All Guides](/guides) Commercial SaaS Monitoring # Monitoring Stripe Webhook Reliability Ensure payment events never silently fail. Learn how to verify webhook delivery, retry logic, and alerting. 11 min read Guide Published Mar 5, 2025Updated Nov 7, 2025 ## 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](/glossary/ssl-tls "Glossary: SSL") handshake, Stripe marks the delivery as failed and retries with [exponential backoff](/glossary/exponential-backoff "Glossary: 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](/glossary/webhook-secret "Glossary: 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](/glossary/keyword-monitor "Glossary: 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's free plan includes 10 commercial-safe monitors with multi-region validation — free forever, no card. [Start Monitoring Free](/auth?signup=true) ## Detecting Silent Delivery Failures Endpoint monitoring catches obvious failures, but not the trickier ones: Stripe disabled your endpoint, [signature verification](/glossary/signature-verification "Glossary: 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. Related Reading - [→ Heartbeat Monitoring for Cron Jobs & Scheduled Tasks](/guides/heartbeat-monitoring-cron-jobs) - [→ SSL Certificate Expiry Monitoring](/guides/ssl-certificate-expiry-monitoring) ## Alerting for Webhook Failures Webhook endpoint failures deserve the highest alert [severity](/glossary/severity "Glossary: 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. Related Reading - [→ Building an Incident Response Playbook](/guides/incident-response-playbook) - [→ Status Page Best Practices for SaaS](/guides/status-page-best-practices) ## Frequently Asked Questions ### How long does Stripe retry failed webhooks? ### What status code should my webhook endpoint return? ### Should I monitor every webhook endpoint or just the billing one? ### Can I monitor the webhook response time? ### What's the difference between Stripe Dashboard delivery monitoring and external monitoring? ### How do I handle webhook signature verification failures? ### What if my webhook endpoint goes down during a deploy? ### Should I expose my webhook endpoint publicly or behind auth? #### Related Guides [How to Monitor SaaS Revenue-Critical Endpoints 8 min ](/guides/monitoring-saas-revenue-endpoints)[Uptime SLA Reporting for SaaS Companies 12 min ](/guides/uptime-sla-reporting-for-saas)[Status Page Best Practices for SaaS 10 min ](/guides/status-page-best-practices)[Can You Use UptimeRobot for Commercial SaaS? 11 min ](/guides/uptimerobot-commercial-use) #### Compare FourSight [vs UptimeRobot →](/compare/uptimerobot-alternative)[vs StatusCake →](/compare/statuscake-alternative)[vs Pingdom →](/compare/pingdom-alternative) 10 free commercial-safe monitors [View Pricing](/pricing) ## Protect Your SaaS Revenue Start monitoring in under 60 seconds. [Start Monitoring Free](/auth?signup=true)[View Pricing](/pricing) FourSight © 2026 [TetraCore](https://tetracorehq.com/). All rights reserved. FourSight is a TetraCore product — Bowling Green, Ohio. Product [Pricing](/pricing)[Guides](/guides)[Glossary](/glossary)[FAQ](/faq)[About](/about)[For Agencies](/solutions/agencies)[For Startups](/solutions/startups)[Privacy](/privacy)[Terms](/terms) Features [Cron Job & Heartbeat Monitoring](/features/cron-job-monitoring)[SSL Certificate Monitoring](/features/ssl-monitoring)[Status Pages](/features/status-pages)[Domain Expiry Monitoring](/features/domain-expiry-monitoring)[DNS Monitoring](/features/dns-monitoring)[Port Monitoring](/features/port-monitoring) Compare [All comparisons](/compare)[vs UptimeRobot](/compare/uptimerobot-alternative)[vs StatusCake](/compare/statuscake-alternative)[vs Freshping](/compare/freshping-alternative)[vs Pingdom](/compare/pingdom-alternative)[vs Pulsetic](/compare/pulsetic-alternative)[vs Better Stack](/compare/better-stack-alternative)[vs Uptime Kuma](/compare/uptime-kuma-alternative)[vs Cronitor](/compare/cronitor-alternative)[vs Healthchecks.io](/compare/healthchecks-alternative)[vs Hyperping](/compare/hyperping-alternative) Pricing Guides [UptimeRobot Pricing](/compare/uptimerobot-pricing)[StatusCake Pricing](/compare/statuscake-pricing)[Pingdom Pricing](/compare/pingdom-pricing)[Better Stack Pricing](/compare/better-stack-pricing)[Uptime Kuma Pricing](/compare/uptime-kuma-pricing)[Cronitor Pricing](/compare/cronitor-pricing)[Healthchecks.io Pricing](/compare/healthchecks-pricing)[Hyperping Pricing](/compare/hyperping-pricing)[Pulsetic Pricing](/compare/pulsetic-pricing)