Subscribe to UpdatesSubscribe
Visit our support site.
Major outage
Partial outage
No downtime recorded on this day.
No data exists for this day.
had a major outage.
had a partial outage.
Related
No incidents or maintenance related to this downtime.
REST API Latency (Singapore)
Fetching
REST API Latency (North Virginia)
Fetching
REST API Latency (Frankfurt)
Fetching
Past Incidents
Feb 20, 2026
No incidents reported today.
Feb 19, 2026
No incidents reported.
Feb 18, 2026
No incidents reported.
Feb 17, 2026
Resolved -
Performance has returned to normal levels. This incident has been resolved.
Feb 17, 00:29 UTC
Feb 17, 00:29 UTC
Monitoring -
We've identified degraded performance in a Supavisor cluster resulted in elevated connection latency and increased p99 response times. The problematic node has been replaced and performance is returning to normal levels. We will continue to monitor.
Feb 17, 00:16 UTC
Feb 17, 00:16 UTC
Investigating -
Starting from Feb 22:55 UTC, degraded performance in one of our Supavisor clusters resulted in elevated connection latency and increased query p99 response times.
Feb 16, 23:48 UTC
Feb 16, 23:48 UTC
Feb 16, 2026
Resolved -
Degraded performance in a Supavisor cluster resulted in elevated connection latency and increased p99 response times between 2026-02-15 22:00 and 2026-02-16 01:00. The problematic node was replaced and performance returned to normal levels.
Feb 16, 01:00 UTC
Feb 16, 01:00 UTC
Feb 15, 2026
No incidents reported.
Feb 14, 2026
No incidents reported.
Feb 13, 2026
Postmortem -
Read details
Feb 14, 03:27 UTC
Feb 14, 03:27 UTC
Resolved -
Service has been fully restored. All impacted jobs have been requeued and are currently processing normally. We will be publishing a public post-mortem with additional details about this incident.
Feb 13, 01:53 UTC
Feb 13, 01:53 UTC
Monitoring -
The revert of the change helped and most of the metrics are back to the pre incident levels. We are requeuing failed jobs and monitoring to make sure the issue doesn’t come back.
Feb 13, 01:26 UTC
Feb 13, 01:26 UTC
Identified -
We identified a potential internal networking configuration that may have caused the incident. We have since reverted that change and it appears services are recovering.
Feb 13, 01:04 UTC
Feb 13, 01:04 UTC
Update -
We are still investigating the root cause for this incident. us-east-2 region isn’t receiving any network traffic at this point. We are also seeing some API request errors in other US regions, but not as high as us-east-2.
Feb 12, 23:58 UTC
Feb 12, 23:58 UTC
Update -
We continue to see increased levels of 500 errors across US-West and US-East regions. Our engineering team is investigating the issue.
Feb 12, 22:57 UTC
Feb 12, 22:57 UTC
Update -
The issue identified it as a problem in US-West with some impact in US-East and the impact seems to be primarily on reads rather than writes.
Feb 12, 22:37 UTC
Feb 12, 22:37 UTC
Investigating -
We have identified increasing 500 errors in some US regions and are actively investigating the cause.
Feb 12, 21:32 UTC
Feb 12, 21:32 UTC
Feb 12, 2026
Feb 11, 2026
No incidents reported.
Feb 10, 2026
Resolved -
This issue is now resolved.
Feb 10, 21:28 UTC
Feb 10, 21:28 UTC
Update -
We continue to work with network vendors to mitigate this issue. In the interim, using a VPN will give you access to your Supabase project.
Feb 10, 15:24 UTC
Feb 10, 15:24 UTC
Update -
We are actively working with network vendors to mitigate this issue.
Feb 4, 18:08 UTC
Feb 4, 18:08 UTC
Identified -
We have noticed increase connection failures to supabase.co domains from connections originating in Yemen.
Projects are up and running, this only impacts connections from this region. We are working to resolve this issue with appropriate parties and will provide an update soon.
We have specifically had reports of connection issues from connections via these ISPs:
Yemen Mobile
Sabafon
Y-Telecom
Spacetel
Feb 3, 21:38 UTC
Projects are up and running, this only impacts connections from this region. We are working to resolve this issue with appropriate parties and will provide an update soon.
We have specifically had reports of connection issues from connections via these ISPs:
Yemen Mobile
Sabafon
Y-Telecom
Spacetel
Feb 3, 21:38 UTC
Feb 9, 2026
Resolved -
This incident has been resolved.
Feb 9, 19:34 UTC
Feb 9, 19:34 UTC
Update -
The team noticed that some connection pools had workers stuck as a consequence of the previous issue. This could cause query failures. Stuck workers were now restarted.
Feb 9, 18:37 UTC
Feb 9, 18:37 UTC
Monitoring -
We've removed the problematic cluster node and latency returned to the normal level. We are now monitoring.
Feb 9, 17:56 UTC
Feb 9, 17:56 UTC
Investigating -
We’re investigating high latency in us-west-1 affecting some connections to databases via our shared connection pooler.
Feb 9, 17:39 UTC
Feb 9, 17:39 UTC
Feb 8, 2026
No incidents reported.
Feb 7, 2026
No incidents reported.
Feb 6, 2026
Resolved -
Function deploys are working normally now. We are resolving this incident.
Feb 6, 01:00 UTC
Feb 6, 01:00 UTC
Monitoring -
esm.sh maintainers have implemented a fix which should unblock deploys of Edge Functions that were importing supabase-js from esm.sh.
Feb 5, 23:53 UTC
Feb 5, 23:53 UTC
Update -
We’ve attempted several fixes on the npm registry side, but the esm.sh issue persists. We are continuing to investigate. In the meantime, use npm: or jsr: specifiers, or jsdelivr as an alternative CDN:
import { createClient } from "npm:@supabase/supabase-js@2.95.0"
or
import { createClient } from "https://cdn.jsdelivr.net/npm/@supabase/supabase-js@2.95.0/+esm"
Feb 5, 21:36 UTC
import { createClient } from "npm:@supabase/supabase-js@2.95.0"
or
import { createClient } from "https://cdn.jsdelivr.net/npm/@supabase/supabase-js@2.95.0/+esm"
Feb 5, 21:36 UTC
Identified -
We are removing v2.95.0 release, so the @2 tag will resolve to v2.94.1. This should resolve majority of issues.
If you have previously switched to using v2.95.0 directly, please switch to v2.94.1
Feb 5, 20:11 UTC
If you have previously switched to using v2.95.0 directly, please switch to v2.94.1
Feb 5, 20:11 UTC
Update -
We recommend importing via `npm:` or `jsr:` specifiers instead of CDN imports:
`import { createClient } from "npm:@supabase/supabase-js@2.95.0"`
These are more reliable than third-party CDNs. We’ve reached out to the esm.sh maintainer and are tracking the issue upstream.
Feb 5, 19:08 UTC
`import { createClient } from "npm:@supabase/supabase-js@2.95.0"`
These are more reliable than third-party CDNs. We’ve reached out to the esm.sh maintainer and are tracking the issue upstream.
Feb 5, 19:08 UTC
Investigating -
Edge Functions using @supabase/supabase-js@2.95.0 from esm.sh are failing. The issue is specific to the esm.sh CDN.
Workarounds: Pin to v2.94.0 or use cdn.jsdelivr.net (https://cdn.jsdelivr.net/npm/@supabase/supabase-js@2.95.0/+esm) as a workaround while we investigate.
Feb 5, 18:09 UTC
Workarounds: Pin to v2.94.0 or use cdn.jsdelivr.net (https://cdn.jsdelivr.net/npm/@supabase/supabase-js@2.95.0/+esm) as a workaround while we investigate.
Feb 5, 18:09 UTC