Stripe's API threw a burst of elevated errors and slow responses for 28 minutes early on 1 October 2026. Stripe's own account of the problem is narrower than the window it opened the incident with, and the fault sits on Stripe's side, not yours.
Started
02:38 UTC
Duration
Lasted 28m
Source
IsDown
Next time
Stripe is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
Affected components: Stripe API
What happened?
Stripe opened an incident at 02:38 UTC, saying it was investigating elevated error rates and response times with the API. No further updates followed until the incident closed at 03:02 UTC, 28 minutes after it started. The resolution note narrowed the actual problem to a four-minute span, 02:24 to 02:27 UTC, describing a brief increase in HTTP 5XX processing errors. That means the stated fault window is shorter than the time the incident stayed open on Stripe's status page. Only one component was listed as affected, the Stripe API, and there was only one incident filed for the day. Stripe published two updates in total: the initial investigating note and the resolved note. No user reports were filed during this window. Over the past 90 days Stripe has logged 26 incidents with a median duration of 1 hour 14 minutes, so this one resolved faster than typical. Across all time Stripe has filed 236 incidents, averaging 3.7 a month. There is no post-mortem here, and Stripe has not said what caused the 5XX errors.
Learning
UptimeRobot's own probes against Stripe's API, checked every 60 seconds from both EU and North American regions, show 100% uptime over the last 24 hours, 7 days and 30 days, and this incident was not registered as a probe-detected event. That is not a contradiction. A four-minute burst of 5XX errors can land between polling intervals, or affect only a subset of requests, while Stripe's own systems still catch and log it internally. External checks are built to catch sustained or repeated failures, not every brief processing error that a provider's backend logs and clears within minutes. This is the shape to recognise in your own product: payment calls failing or timing out for your users while your uptime dashboard stays green, because the fault lived inside Stripe's processing layer rather than in reachability. Your own monitoring tells you your endpoints are up. It does not tell you whether Stripe's API is quietly erroring underneath you. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
