Supabase logged two separate incidents on 22 October, both tied to project and management API operations rather than your database connections directly. One began in the EU region before midnight and ran into the morning, the other hit the Management API across multiple regions from mid-morning. Both faults sit on Supabase's control plane, not on your product.
Started
03:53 UTC
Duration
Lasted 12h 6m
Source
IsDown
Next time
Supabase 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.
What happened?
Supabase's status page shows two incidents on this day. The first started at 03:53 UTC, covering increased error rates in project lifecycle operations, meaning creates, restores and pauses, in the EU region. Supabase says the underlying errors actually began the night before, at 21 Oct 23:00 UTC, and had already pushed a mitigation by the time this incident was filed. By 09:15 UTC error rates were reported as back to normal, with Supabase stating it was continuing to monitor before calling the incident resolved. No resolved update is on record for this one, so it is still open as far as the public timeline shows. The second incident started at 11:29 UTC and concerned elevated error rates and response times on the Management API across multiple regions, not just the EU. Supabase's own text is specific about the blast radius: operations depending on the Management API, such as creating new projects, could fail or run slow, and logins to supabase.com were timing out as a knock-on effect. By 12:07 UTC Supabase reported a mitigation applied and error rates and latency back to normal levels, again moving to a monitoring state rather than a resolved one. Neither incident lists specific components affected on the page, and no user reports were filed during the window on this record. Across both incidents, the pattern is the same: an initial spike, a mitigation applied quickly, and a monitoring period with no confirmed closure logged.
Learning
Both incidents here sit in Supabase's control plane, the layer that handles project creation, pauses, restores and the Management API, rather than in the data path your running queries use. That distinction matters because a check that only pings your database or your deployed functions can stay green while project lifecycle actions and the Management API are failing behind the scenes. Supabase's own figures give some scale: over the last 90 days it logged 56 incidents with a median duration of 2 hours 5 minutes, and across all time it averages 7.6 incidents a month, so this is a provider with a frequent incident cadence rather than a one-off bad day. If your deployment pipeline or admin tooling calls the Management API directly, an outage like the second one here would break your workflow even though your live application kept serving traffic normally. Watching only your own endpoints will not surface this kind of fault, because the fault lives upstream of anything your product touches. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
