Know when Stripe paymentsstart failing

10 min · you have a Stripe account · updated 23 August 2026

Of everything that can break quietly, payments are the worst. The product looks fine. Nothing 500s. Customers are being turned away, one at a time, and the first signal is usually a support email hours later — or a revenue dip you spot the following week.

What Stripe already gives you

Worth being clear about, because you may not need another tool.

Stripe emails you about some events, shows failures in the dashboard, and can send webhooks for everything. If you already consume payment_intent.payment_failed in your own code and alert on it, you have this covered.

What Stripe will not do is tell you when your handling of those events breaks — if your webhook endpoint starts returning 500, Stripe retries and eventually gives up, and the dashboard still shows the payment as fine. It also has no opinion about your baseline: it cannot tell a normal trickle of card declines from a sudden cliff.

The three failure modes

1. Payments failing at a higher rate than normal. Cards decline all the time — a handful a day is business as usual, not an incident. What matters is a change in rate, particularly a sharp one, which usually means something on your side: a broken price, an expired key, a misconfigured tax setting.

2. Your webhook endpoint failing. Stripe successfully charges the customer, calls your endpoint, and your endpoint errors. Money is taken, fulfilment never runs. This is the worst version because everything upstream reports success.

3. Payments stopping entirely. No failures, no successes — the quietest possible outage, and one that pure error-rate monitoring cannot see, because zero errors looks perfect.

What Beaam watches

Connect with a restricted, read-only Stripe key. Beaam polls the Events API every minute and alerts on payment_intent.payment_failed:

More than one payment failure in a five-minute window → broken

Deliberately blunt. For a small product, several failures inside five minutes is almost never normal, and a threshold you have to tune is one you will not tune. Repeated evidence is still required before it fires, so a single decline stays quiet.

Cover the webhook endpoint too

The payment signal does not cover failure mode 2 — your own endpoint erroring. Add your webhook URL as an HTTP check so Beaam alerts if it stops responding.

The stronger version, if your endpoint is a Lambda or a serverless function: connect that provider as well. Beaam treats any Lambda error in the window as broken, which catches a handler throwing on a payload it did not expect — the common cause of silently unfulfilled orders.

What this still will not catch

• Payments stopping entirely. Absence of events is not currently an alert. If checkout volume is steady enough to have a baseline, that is a real gap.
• Wrong amounts. Beaam sees that a payment failed, not that it succeeded for the wrong price.
• Business-logic failures. A charge that succeeds but grants the wrong entitlement looks perfect from outside.

Those need instrumentation only you can write. If you already emit OpenTelemetry, point it at Beaam and alert on your own counters.

A sensible setup

1. Connect Stripe with a restricted key — payment failures covered.
2. Add your webhook endpoint as an HTTP check — endpoint availability covered.
3. Connect the provider running your webhook handler — handler errors covered.
4. Send a test alert and confirm it reaches your phone.

Three connections, and the money path has coverage at each layer rather than just the first.

---