Supabase's API Gateway has been running with intermittent latency for clients in the eastern US since 16:26 UTC on 29 September, and the issue is still open. Supabase has traced it to a specific point of presence but has not yet published a final fix.
Started
16:26 UTC
Duration
Ongoing
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: API Gateway
What happened?
Supabase logged this incident at 16:26 UTC under the title "Intermittent latency in Eastern US", affecting the API Gateway component. The first update described bursty traffic causing latency spikes for clients in the eastern US, most noticeable around the :00 and :30 hour marks during EDT working hours. By 17:55 Supabase clarified the scope: this hits any client connecting from the eastern US, including servers and serverless functions, regardless of where the Supabase project itself is hosted. At 21:35 Supabase said a mitigation had been applied but it did not yet have evidence that it had helped, and it had tied the problem to a particular point of presence, working with networking partners toward a fix. Updates continued overnight and into the following day at 02:14 and 14:54, both saying only that work with networking partners was continuing, with no estimated resolution time given. At 21:26 Supabase reported signs of improvement. The most recent update, at 20:23, states that Supabase's networking partners applied a mitigation at the problematic point of presence and that Supabase has observed significant improvement in high-latency rates across the region, though it is still working to isolate any additional root causes. No update on this incident has declared it resolved. No user reports were filed during this window. Over the past 90 days Supabase has logged 54 incidents with a median duration of 2 hours 4 minutes, and this one has already run well past that median.
Learning
This incident sits at the network layer, inside a specific point of presence that Supabase's own infrastructure routes through, not inside your application code or your project's configuration. That is why pinging your own endpoints from your own servers would not reliably have shown you this: the latency only appears for clients physically routing through that eastern US point of presence, and only during bursty traffic windows around the hour and half hour marks. A check run from outside that path, or outside those windows, can come back clean while real requests from affected users are stalling. Supabase's own update history backs this up, it has taken multiple days and several rounds of coordination with networking partners to even get a partial mitigation in place. If your product serves eastern US traffic through Supabase, this is the shape of failure to recognise: steady baseline performance punctuated by latency spikes tied to time of day and geography, not a clean up or down state. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
