Supabase's log ingestion pipeline fell behind for 51 minutes on 28 September 2026. The company says a scaling gap on their side caused delayed delivery of logs, not data loss in your actual database or API traffic.
Started
13:47 UTC
Duration
Lasted 51m
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 logged one incident on this day, called Log Ingestion Degradation, starting at 13:47 UTC and lasting 51 minutes. The first update said log ingestion was experiencing delays and that clients would retry ingestion automatically. Five minutes later, at 13:52 UTC, Supabase identified the cause as a scaling gap and said the relevant resources had been scaled up, with ingestion recovering. By 14:00 UTC the company reported ingestion had recovered and said it was monitoring for continued stability. The incident was marked resolved at 14:36 UTC with a one-line update stating log ingestion was normal. No components are listed as affected in Supabase's own breakdown, and no user reports were filed during this window. The entire incident ran for four updates total, all shown here, with no further detail on which log types or projects were delayed. Supabase's status page does not say how many clients were affected or whether any log data was permanently lost rather than delayed. Over the last 90 days Supabase has logged 54 incidents with a median duration of 2 hours 4 minutes, so this one resolved well under that typical length. Across its full history the company has averaged 7.4 incidents per month.
Learning
This incident sat in Supabase's logging pipeline, a layer that sits behind your database and API calls rather than inside them. If your product writes queries and serves requests normally while logs lag behind, your own health checks on your endpoints will stay green because the actual data path kept working. That is exactly the kind of split this incident shows: a real degradation on the provider's side that would not show up if you were only watching your own service from the outside. UptimeRobot's own monitoring over the last 30 days recorded 19 incidents for Supabase with a median duration of 2 hours 12 minutes, a different count and duration from what Supabase itself reports, because external checks and status page entries measure different things and neither is wrong. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
