Blog

A successful test-mode checkout proves that one request worked once. It does not prove that billing, provisioning, and entitlement state will remain correct when delivery gets slow, repeated, reordered, or interrupted.

Stripe's webhook guidance says to expect automatic retries, duplicate events, and delivery that is not ordered. It also recommends signature verification and asynchronous handling.

1. Duplicate delivery

Deliver the same event ID twice, including two requests at the same time.

Invariant: one event produces one irreversible side effect. A duplicate must not create another credit, email, shipment, or entitlement change.

2. Out-of-order delivery

Deliver a later subscription event before an earlier lifecycle event.

Invariant: local state converges to Stripe's current state instead of blindly trusting arrival order.

3. Handler timeout

Hold a dependency open until the request exceeds the normal response window.

Invariant: the event remains recoverable. A timeout must not leave a completed side effect without a durable receipt, or an acknowledgement without queued work.

4. Retried 5xx

Return a controlled server error, then allow the retry to succeed.

Invariant: retry completes missing work once and does not repeat work already committed during the failed attempt.

5. Manual replay

Replay a previously accepted event after the normal processing window.

Invariant: replay is observable and idempotent, so operators can recover missed work without creating a second business transaction.

6. Invalid signature

Send a valid body with a bad signature, a stale timestamp, and a body modified after signing.

Invariant: every invalid request fails closed before business logic runs, without logging secrets or sensitive payloads.

7. Queue failure

Make enqueueing fail after receipt, and make a worker fail after dequeueing.

Invariant: acknowledgement matches durability. Failed jobs remain retryable or reach a monitored dead-letter path with enough context to recover them.

8. Missing-event reconciliation

Create a state change that the webhook consumer never receives.

Invariant: a scheduled or operator-triggered reconciliation detects drift and repairs it from Stripe's source of truth.

Keep evidence, not just a checkmark

For each case, record the business invariant, stimulus, HTTP and state evidence, and a pass, fail, or not-testable result with reproduction steps. The useful answer is whether paid customer state can become wrong and whether the team can detect and repair it.

SDNBros runs these cases as a fixed $950 Stripe Webhook Failure Drill for one integration and up to three handlers. Delivery is within 48 hours after accepted scope, deposit, access, and handler inventory. Review the fictional sample report before requesting a scope call.

Every developer who integrates with webhooks has been there: a payment fails silently, an order doesn't sync, a deployment never triggers. You check the logs. Nothing. The webhook fired into a void and you have no idea why.

We built Webhook (SDNBros Webhooks) because we were tired of this. Tired of curl-ing our own endpoints to reproduce issues. Tired of adding console.log to figure out what payload shape Stripe actually sends. Tired of customers reporting bugs that happened because a webhook silently failed three hours ago.

Capture First, Debug Later

Webhook sits between your webhook provider and your application. Every event is captured and stored the instant it arrives, before any forwarding happens. If your app is down, restarting, or returning errors, you don't lose a single event.

Point your provider's webhook URL at https://webhook.sdnbros.app/p/{your-token} and events start flowing. Your app gets them forwarded automatically with retries, and you get a full timeline of what happened.

Automatic Root Cause Analysis

When a delivery fails, Webhook doesn't just show you "HTTP 500." Our provider-aware diagnosis engine analyzes the failure in context:

• Is it a timeout, DNS failure, TLS issue, or application error?
• Is your endpoint returning 401 because the auth token expired?
• Is Shopify rate-limiting your endpoint?
• Is this a pattern — the same event type failing repeatedly?

You get actionable suggestions, not raw HTTP status codes.

Replay with Confidence

The most requested feature in webhook tooling is replay. But replaying a payment_intent.succeeded event can double-charge a customer. Webhook's replay engine checks idempotency semantics per provider and event type, warns you about side effects, and lets you make an informed decision.

New in v1.5: you can replay to any URL — send the original payload to localhost, staging, or a teammate's endpoint for debugging.

Your Webhooks, Your CLI

Install the CLI and get production webhooks on your laptop in seconds:

curl -sSL https://sdnbros.app/install.sh | sh
sdnbros tunnel --port 3000

No ngrok. No Cloudflare tunnels. Just your real production events forwarded to localhost via WebSocket.

Start Free

Webhook is free for small projects — 1,000 events/month, 3-day retention, no credit card. Starter is $19/month with replay and signature verification; Pro is $49/month with smart routing, 30-day retention, and analytics. See pricing or sign up and start capturing.

When a webhook delivery fails, the raw signal is minimal: an HTTP status code, maybe an error message, maybe nothing at all. Turning that into an actionable diagnosis requires context that a generic monitoring tool doesn't have.

The Problem with Generic Error Monitoring

A 403 from Stripe means your webhook signing secret is wrong. A 403 from Shopify might mean your app hasn't completed the OAuth handshake. A 403 from your own API means your auth middleware rejected the request. Same status code, completely different root causes.

Layered Analysis

Our diagnosis engine runs three layers of analysis on every failed delivery:

1. Network Layer — DNS resolution failures, TLS handshake errors, connection timeouts, connection refused. These tell you the problem is infrastructure, not code.
2. HTTP Layer — Status code classification with provider context. A 429 from Stripe means you need to handle rate limits differently than a 429 from your own reverse proxy.
3. Application Layer — Framework-specific error detection. Is your endpoint returning a Django debug page? A Rails exception? A JSON parsing error?

Provider Registry

Each supported provider (Stripe, Shopify, GitHub, Twilio, SendGrid) has a registry entry that defines:

• Detection rules — How to identify the provider from HTTP headers
• Event catalog — Known event types with idempotency semantics
• Error patterns — Provider-specific failure signatures
• Replay safety — Which events are safe to replay, which are dangerous

Zero-Latency Classification

Provider detection and event classification happen on the ingest hot path. By the time an event hits your dashboard, we already know it's a payment_intent.succeeded from Stripe with idempotency key pi_xxx. The diagnosis engine runs asynchronously after a delivery failure, so it never slows down the forwarding pipeline.

The best debugging tool is one that tells you what's wrong before you even ask.

We're adding more providers and deeper analysis with every release. Check the changelog to follow along.

A webhook failed. Your instinct is to hit "retry" and move on. But webhook replay is one of the most deceptively dangerous operations in distributed systems.

The Double-Charge Problem

Consider a payment_intent.succeeded event from Stripe. Your handler provisions the user's subscription, sends a welcome email, and updates the CRM. If the first delivery succeeded but your monitoring shows a timeout (because the response was slow), replaying the event provisions the subscription again, sends a duplicate welcome email, and creates a duplicate CRM entry.

This isn't hypothetical. It's one of the most common webhook integration bugs.

Idempotency Is Provider-Specific

Not all events are created equal:

• Safe to replay: Stripe customer.updated — the payload contains the full current state, so processing it twice produces the same result.
• Conditionally safe: GitHub push — safe if your handler checks the commit SHA, dangerous if it triggers a deployment unconditionally.
• Dangerous: Stripe invoice.paid — replaying can trigger duplicate fulfillment if your handler doesn't check for existing transactions.

How Webhook Makes Replay Safe

Before every replay, Webhook's engine evaluates:

1. Was this event already delivered successfully? If yes, you're about to send a duplicate.
2. What are the idempotency semantics? Based on the provider and event type, is this replay inherently safe?
3. Does the event carry an idempotency key? If so, well-written handlers will deduplicate automatically.
4. Is this a test/sandbox event? Test events are always safe to replay.

You get a clear verdict: Safe, Conditional, or Dangerous — with a confidence score and specific warnings.

Replay to Any URL

Sometimes you don't want to replay to production at all. Maybe you want to send the exact payload to your localhost to reproduce a bug. Or to a staging endpoint to test a fix before deploying. Webhook v1.5 lets you replay any event to any URL — your production destination or somewhere else entirely.

Private IPs are blocked (SSRF protection), but everything else is fair game. The original payload, headers, and method are preserved exactly as the provider sent them.

Try it out — replay is available on Pro and Business plans.