Supabase had two separate incidents on 24 September 2026, hitting the Dashboard, the Management API and the Database components. The first was a permissions bug in the Dashboard lasting 1h 15m, and the second was a hardware failure in the eu-west-1 region lasting 2h 5m. Both were on Supabase's side.
Started
10:37 UTC
Duration
Lasted 1h 15m
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.
Affected components: Management API, Database, Dashboard
What happened?
The day's first incident started at 10:37 UTC, when Supabase began investigating reports of users hitting permission errors such as "You need additional permissions" when trying to perform administrative actions in the Dashboard. Supabase identified the cause at 10:50, applied a fix by 11:08, and resolved the incident at 11:49, a total of 1h 15m. That incident affected the Dashboard and, by extension, the Management API that backs Dashboard actions. The second incident started at 15:36 UTC and was unrelated. Supabase reported project lifecycle operation issues in eu-west-1, and by 15:50 had traced the problem to an upstream infrastructure issue affecting specific underlying hardware in the region. Supabase's updates describe projects being moved to new hardware in stages: most were back by 16:56, and the rest by 17:03. The incident moved to monitoring at 17:12 and was marked resolved at 17:38, giving a total duration of 2h 5m. This one affected the Database component, since projects on the unhealthy hardware were unreachable until moved. No user reports were filed during either window, so the record of what happened rests entirely on Supabase's own status updates. Supabase did not publish a post-mortem for either incident, and neither update explains what caused the original permissions bug or named the upstream infrastructure provider behind the hardware failure. Across both incidents, Supabase filed 11 updates total.
Learning
This is a case where the failure sat inside Supabase's own infrastructure and management layer, not in your application code, so there was nothing on your end to catch it by watching your own endpoints. A Dashboard permissions bug or a hardware failure in a specific region is the kind of fault that only shows up if something is watching Supabase itself, continuously, from outside. UptimeRobot's 30 day figures for Supabase show 19 incidents with a median duration of 2h 12m, close to the 2 hours 4 minutes median across Supabase's last 90 days of 54 incidents, so this pattern is not unusual for the service. If your own monitoring stayed quiet through either window, that is not a contradiction: your checks were testing whether your product could reach Supabase and get a response, and in both incidents the service was partially degraded rather than fully down, which can pass a basic health check. Your monitoring covers your half of the stack, UptimeRobot now watches the provider's half too, so next time something breaks you know which side it was without guessing.
