Stripe status

How we check Stripe

We watch js.stripe.com/v3/ from all five of our probe regions, every 2 minutes. A region that sees a failure does not make this page say "down" on its own: a second region has to agree first, the same confirmation rule every YoPingMe monitor uses.

We watch the script every Stripe Checkout and Payment Element on the web actually loads, not the API root. api.stripe.com answers 401 to a request carrying no key, which an anonymous monitor that expects a plain 2xx would misread as an outage even while Stripe is completely healthy.

What is Stripe?

Stripe is the payments infrastructure behind a large share of the checkout forms, subscription billing, and invoicing on the internet. Rather than running card processing yourself, a business calls Stripe's API or drops in one of its hosted UI elements, and Stripe handles the parts that would otherwise mean months of compliance work: talking to card networks, meeting PCI requirements, and settling funds into a bank account.

That central position is exactly what makes a Stripe incident different from most other outages. When Stripe degrades, the businesses relying on it do not go offline. Their homepage, their product pages, their support widget, everything else keeps working normally. Only the moment a customer tries to pay breaks, and it breaks silently: no red banner, no obvious error on the merchant's own site, just a checkout button that stops doing anything or a payment element that never finishes loading. A team watching only their own server logs can go a surprisingly long time without noticing, because nothing in those logs looks wrong. The failure lives in a script served from Stripe's domain, not in anything the merchant's own infrastructure touched.

The financial shape of the problem matters too. Every minute Stripe is unreachable at checkout is a minute of lost revenue that does not show up as an error rate anywhere convenient, it shows up later as a gap in the day's transaction total that someone has to notice and explain. For a subscription business, a longer outage can also collide with renewal billing, pushing some charges later than customers or internal financial reporting expect.

Stripe's own incidents are typically short and narrow: a single API surface or a specific region degrading rather than a full platform outage, which is part of why the current-status board above is worth checking before assuming the problem is on your end. If it shows Stripe healthy, the checkout failure a customer is describing to your support team is more likely a bug in your integration, an expired or rotated API key, or a webhook that stopped being delivered, not Stripe itself.

Frequently asked questions

Is Stripe down right now?

Check the board above; it reflects our own probes, refreshed every couple of minutes. A single region reporting trouble is not enough for this page to call it down, we wait for a second region to agree first.

What happens to my checkout if Stripe goes down?

The Stripe-hosted checkout page or embedded payment element stops loading or stops accepting cards, so a customer trying to pay sees a blank form, a spinner that never resolves, or an error at the final step. Your own site usually still loads fine, which is part of why the failure is easy to miss until a support ticket arrives.

Does a Stripe outage affect subscriptions that are already running?

Usually not immediately. Existing subscriptions renew on a billing schedule Stripe processes internally, and a short outage typically delays that processing rather than skipping a charge outright. A prolonged outage can push renewal attempts later than your dunning emails expect, so check the Billing section of your Stripe dashboard after any incident lasting more than a few hours.

How is this different from Stripe's own status page?

Their page reflects what Stripe's own engineers have observed and chosen to post. Ours reflects what our probes measured from outside Stripe's infrastructure, on the same schedule regardless of whether anyone at Stripe has written an update yet. Neither replaces the other; read both if you are debugging a live incident.