Supabase Outage History

Error rates have returned to baseline and all regions are operating as expected.

We've seen error rates return to normal levels, and all regions are now holding steady. We will continue to monitor to make sure things remain stable.

We are continuing to see some periodic spikes in error rates; however, total rate of errors are decreasing across most regions. We're continuing efforts to get all systems back to green. When error rates spike, management API functions, which would mean dashboard actions, project creation, configuration changes, and other functions remain impacted. Existing projects are unaffected and connectivity via the Data APIs, Postgres connections, and Supavisor are unaffected.

The team is continuing to deploy mitigations, and we are seeing error rates improve, but are not back to baseline yet. All management API functions, which would mean dashboard actions, project creation, configuration changes, and other functions remain impacted. Existing projects are unaffected and connectivity via the Data APIs, Postgres connections, and Supavisor are unaffected.

We have identified the source of the increased error rates, and are working on a fix now. All management API functions, which would mean dashboard actions, project creation, configuration changes, and other functions remain impacted. Existing projects are unaffected and connectivity via the Data APIs, Postgres connections, and Supavisor are unaffected.

We've expanded this to all management API functions, which would mean dashboard actions, project creation, configuration changes, and other functions would also be impacted. Error rates are currently improving, but the team is investigating the root cause to ensure continued stability. Existing projects are unaffected and connectivity via the Data APIs, Postgres connections, and Supavisor are unaffected.

We are currently investigating the cause, but users may see issues creating projects across all regions. Existing projects are not affected and remain up and stable.

Both regions are now working as usual.

Response times in both the ap-northeast-1 (Tokyo) and ap-northeast-2 (Seoul) regions have now stabilised. We will continue to monitor the systems closely to ensure stability.

Response times in the ap-northeast-1 (Tokyo) region have improved following mitigation efforts. We are currently rolling out the fix to the ap-northeast-2 (Seoul) region. Further updates will be provided as the rollout continues.

We are continuing to investigate reports of Edge Functions experiencing high response times in Asia Pacific regions Our team is still working to determine the underlying cause. We understand the disruption this may be causing and are treating this with high priority.

We are continuing to investigate reports of Edge Functions experiencing high response times in Asia Pacific regions Our team is still working to determine the underlying cause. We understand the disruption this may be causing and are treating this with high priority.

We are currently investigating the cause for increased response times.

The issue affecting Edge Functions has now been fully resolved, and users have reported Edge Functions operating as expected. The root cause was a denial-of-service event that led to elevated error rates and 504 responses across impacted regions. Mitigations have been implemented to restore stability. We will be publishing a full post-mortem with additional details, once our internal review is complete. Thank you for your patience while we worked to resolve this issue.

The fix has been implemented and early indicators suggest it has resolved the 504 errors affecting Edge Functions. We are continuing to monitor system performance closely to ensure stability and confirm full recovery across all affected regions. We will provide a final update once we are confident the issue is fully resolved.

We believe we have identified the underlying cause of the 504 errors affecting Edge Functions across multiple regions. The team are currently implementing corrective measures to address the issue and restore service stability.

We are continuing to investigate reports of Edge Functions returning 504 errors across multiple regions. Our team is still working to determine the underlying cause. We understand the disruption this may be causing and are treating this with high priority.

We are currently investigating reports of Edge Functions returning 504 errors across multiple regions. The team has been alerted and is actively investigating the root cause. We are working to identify the scope of affected regions. We will provide an update as soon as we have more information.

Systems have remained stable, and we are confident the issue has been resolved.

Connection and query times are back to normal levels. We will continue monitoring to ensure stability.

The team is investigating connectivity issues via Supavisor in EU-Central-1. Data API, direct connections, and connections via the dedicated pooler are unaffected. You can read more on the dedicated pooler here: https://supabase.com/docs/guides/database/connecting-to-postgres#dedicated-pooler

Metrics collection continues to operate normally in US-West-2, and full metrics collection has been fully restored with no blips in stability.

The team has deployed additional capacity and has restored metrics collection operations. All metrics collection in region is fully operational and the team is actively monitoring the fixes deployed.

The team has deployed a fix and is actively monitoring recovery of partially degraded metrics collection. Some US-West-2 users may see metrics periodically available, but others may still see missing metrics. This does not impact project availability or functionality, which remain healthy.

The team is continuing to work on a fix for metrics collection. Some US-West-2 users may see metrics periodically available, but others may still see missing metrics. We'll continue to update here as we have more information. This does not impact project availability or functionality, which remain healthy.

We have identified the components resulting in the delayed metrics collection, and the team is working on a fix. This does not impact project availability or functionality, which remain healthy.

We have discovered an issue with metrics collection for projects in US-West-2. Some users may not be able to see metrics for these projects in the dashboard, and functions such as automatic disk resizes may be delayed as well. This does not impact project availability or functionality, which remain healthy. The team is currently investigating.

We’ve published a [post-mortem on our blog](https://supabase.com/blog/supabase-incident-on-february-12-2026).

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.

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.

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.

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.

We continue to see increased levels of 500 errors across US-West and US-East regions. Our engineering team is investigating the issue.

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.

We have identified increasing 500 errors in some US regions and are actively investigating the cause.

This incident has been resolved.

Our upstream provider has pushed a fix, and requests seem to be back to normal now. According to data from our partner, users in the US South were largely affected, with users in and around Texas being the most common, but some users in and around Georgia may have also seen issues, but these should all be resolved at this point. Users connecting to project URLs should no longer be seeing "DNS address could not be found" errors. We are continuing to monitor the situation.

Our upstream provider has identified the specifc issues with DNS resolution and has begun working on a fix. Projects and the underlying infrastructure are unaffected, and remain running and available for users without affected DNS Providers. Affected users will see errors similar to "DNS address could not be found"

We are continuing to work on this with our upstream network provider. Projects and the underlying infrastructure are unaffected, and remain running and available for users without affected DNS Providers. Affected users will see errors similar to "DNS address could not be found"

Our upstream network provider has identified an issue and is working on a fix. Projects and the underlying infrastructure are unaffected, and remain running and available for users without affected DNS Providers. Affected users will see errors similar to "DNS address could not be found"

We are seeing reports of DNS Lookup failures for users based in the United States. The issue does not seem to affect all DNS providers, and we are still working to narrow down affected areas. Projects and the underlying infrastructure are unaffected, and remain running and available for users without affected DNS Providers. Affected users will see errors similar to "DNS address could not be found"

This issue is now resolved.

New project creation and unpauses are now available. We are working on remediation of projects impacted during the incident and will continue to monitor.

We have identified the issue and are working towards a resolution.

We are investigating issues affecting instance operations globally. This may impact new project creation and project unpauses. Existing projects remain unaffected.

This incident has been resolved.

A fix has been implemented and we are monitoring the results.

We are currently investigating this issue.

This incident has been resolved.

Project actions (creation, unpauses, read replica creation, upgrades) have been re-enabled, and the team is monitoring.

We have received word from our upstream partner that their issue has been resolved. The team is currently testing all functionality on our side and cleaning up previously errored requests. Once we're confident things are back to normal, we'll resume project actions in the region.

We are continuing to monitor for resolution of the upstream provider incident.

We continue to monitor for resolution of the upstream provider incident.

Instance operations in eu-west-1 are impacted by an ongoing infrastructure provider incident causing network issues in the region. Affected operations include new project creation, unpauses, read replica creation, and upgrades. Existing projects are unaffected. Our provider is aware of the issue and we already see error rates and latency trending down. We will update as the situation progresses.

We are investigating issues affecting instance operations in the eu-west-1 region. This may impact new project creation, project unpauses, read replica creation, and upgrades. Existing projects remain unaffected.

Between 6am and 7am UTC our Supavisor cluster experienced instability, resulting in elevated error rates and increased client reconnects. The issue has since been resolved, and the service is operating normally. We are currently reviewing preventative measures to reduce the likelihood of recurrence.

This incident has been resolved.

Log ingestion has been fully restored across all services. We will continue to monitor the system to ensure stability.

We are continuing to work on restoring full log ingestion for Postgres, PostgREST, and Auth services.

We have stabilized the ingestion servers. Error rates are back to normal and the Logflare dashboard is functioning. Our team is now working to restore log ingestion for Postgres, PostgREST, and Auth services.

We continue to see degraded log ingestion across all regions. Logflare dashboard may be temporarily unavailable as well while we take steps to mitigate the issue and restore normal service. Our engineering team is actively working on a resolution. We will provide further updates as we make progress.

We are seeing degradation in log ingestion in all regions, our engineering team is investigating this issue.

This incident has been resolved.

A fix has been deployed, all new projects are fully operational. We've finished backporting the fix to affected projects and now monitoring.

A fix has been deployed, all new projects are fully operational. We're currently backporting the fix to affected projects (69% complete). An immediate workaround is to use custom SMTP. More information available on configuring that here: https://supabase.com/docs/guides/auth/auth-smtp

We've deployed a fix and confirmed all new projects are fully operational. Remediation for previously affected projects is underway and 50% complete. An immediate workaround is to use custom SMTP. More information available on configuring that here: https://supabase.com/docs/guides/auth/auth-smtp

A fix has been deployed, all new projects are now fully operational. We're currently backporting the fix to affected projects (30% complete). An immediate workaround is to use custom SMTP. More information available on configuring that here: https://supabase.com/docs/guides/auth/auth-smtp

We have implemented a fix, and all new projects should now be fully operational. We are rolling out a backporting fix to the affected projects; this is going to take around 3 hours. An immediate workaround is to use custom SMTP. More information available on configuring that here: https://supabase.com/docs/guides/auth/auth-smtp

We have implemented a fix, and all new projects should now be fully operational. We are now working on backporting it to the affected projects. An immediate workaround is to use custom SMTP. More information available on configuring that here: https://supabase.com/docs/guides/auth/auth-smtp

We have identified the issue, and we are working on the fix. An immediate workaround is to use custom SMTP. More information available on configuring that here: https://supabase.com/docs/guides/auth/auth-smtp

We are continuing to investigate this issue. An immediate workaround is to use custom SMTP. More information available on configuring that here: https://supabase.com/docs/guides/auth/auth-smtp

We are currently investigating an issue where some users have reported failures when sending email via the Shared SMTP service. This is also impacting newly creating projects. If you are impacted, and need email services working immediately, you can work around this immediately by following best practice for production use cases and configure custom SMTP: https://supabase.com/docs/guides/auth/auth-smtp

We are currently investigating an issue where some users have reported failures when sending email via the Shared SMTP service. If you are impacted, and need email services working immediately, you can work around this immediately by following best practice for production use cases and configure custom SMTP: https://supabase.com/docs/guides/auth/auth-smtp

We worked with our email provider to restore the shared SMTP service, and email delivery has now fully returned to normal. All emails are being delivered as expected. We’ll be following up internally to implement preventative measures to reduce the likelihood of this happening again.

We are continuing to work on a solution for this issue. 

 To clarify the impact: This only affects the shared SMTP service, which is intended for testing use only.

 The team is, in parallel, continuing to work with our mail provider and is preparing a migration to a different service - we will go with whichever solution happens the earliest; however, this migration must be done carefully to avoid further issues. 
 If you need email services working immediately, you can still work around this immediately by following best practice for production use cases and configure custom SMTP: https://supabase.com/docs/guides/auth/auth-smtp We expect to have an update no later than December 22 at 0900 UTC; however, we will share more information if it becomes available earlier.

We are continuing to work on a solution for this issue. You can still work around this immediately by following best practice for production use cases and configure custom SMTP: https://supabase.com/docs/guides/auth/auth-smtp

We are working with the email provider for shared SMTP services. For now, users without Custom SMTP will continue to see email deliverability issues for auth-related emails. We are also exploring other provider options in the event we need to migrate in the near term. You can still work around this immediately by following best practice for production use cases and configure custom SMTP: https://supabase.com/docs/guides/auth/auth-smtp

We have identified the issues with sending mail via the shared SMTP service and are working on a fix. For any production workloads, we would still strongly encourage setting up custom SMTP on your projects. More information available on configuring that here: https://supabase.com/docs/guides/auth/auth-smtp

All projects using Supabase shared SMTP are experiencing emails going undelivered. We are currently investigating, but an immediate workaround is to use custom SMTP. More information available on configuring that here: https://supabase.com/docs/guides/auth/auth-smtp

We are continuing to investigate this issue.

All projects using Supabase shared SMTP are experiencing emails going undelivered. We are currently investigating, but an immediate workaround is to use custom SMTP. More information available on configuring that here: https://supabase.com/docs/guides/auth/auth-smtp

All projects using Supabase shared SMTP are experiencing emails going undelivered. We are currently investigating, but an immediate workaround is to use custom SMTP. More information available on configuring that here: https://supabase.com/docs/guides/auth/auth-smtp

This incident has been resolved.

We’ve identified the potential root cause of the today’s disruption and we are validating a long-term fix to prevent recurrence. All systems operational.

Project creation and restoration are working again as usual. Our testing confirms normal operation. We’re continuing to investigate the root cause and will provide further updates soon.

The problem has been identified and we're working towards a resolution. Existing projects and running services continue to operate as usual.

New project creation and project restores are currently disabled due to an ongoing issue. Our engineering team is investigating the root cause and working on a fix. Existing projects and running services continue to operate as usual.

This incident has been resolved.

Issues were encountered with the latest deploy. We've reverted the change and error rates have reduced. We'll continue to monitor.

We are currently investigating reports that Edge Function invocations are experiencing high error rates in ap-northeast-2 (Seoul) region. We will provide additional information as soon as it is available.

This incident has been resolved.

The fix was deployed, and the Auth config is now accessible again. We will continue to monitor to make sure that the issue is fully resolved.

We have identified the issue and our Engineering team is working to resolve. Existing auth traffic is not impacted.

We are currently investigating this issue.

Between 09:26 UTC and 09:55 UTC on November 24th 2025, customer projects returned HTTP 556 and 500 errors for 90% of requests to multiple products. ### Timeline | Time | Description | | --- | --- | | 09:26 UTC | API Gateway deployment. Customer impact starts. | | 09:30 UTC \(\+04 mins\) | Multiple product teams report monitoring anomalies and an influx of support tickets indicating problems with the Management API. | | 09:38 UTC \(\+12 mins\) | Incident is declared internally. | | 09:40 UTC \(\+14 mins\) | Status page post is created. | | 09:43 UTC \(\+17 mins\) | A recent deploy was rolled back as a precautionary step. | | 09:43 UTC \(\+17 mins\) | The team continued investigating various causes to the issue. We saw varied reports of Management API downtime, as well as errors manifesting in the Product services. | | 09:52 UTC \(\+26 mins\) | Root cause identified as a recent API Gateway release. | | 09:55 UTC \(\+29 mins\) | Rollback of API Gateway release. Customer impact ends. | ‌ ### Who was affected? 90% of requests via our API Gateway resulted in errors, which includes requests for our Data API, Auth, Storage, Realtime and Functions products - affecting customer projects in all regions. Direct Database connections and Supavisor connections were not impacted. Additionally our Management API was affected, and customers may have experienced errors when taking actions to manage their Supabase organization or projects. | **Service** | **Impact** | | --- | --- | | Data API | Impacted | | Auth | Impacted | | Storage | Impacted | | Realtime | Impacted | | Functions | Impacted | | Management API | Partially Impacted | | Direct Database connections | Not impacted | | Supavisor connections | Not impacted | ‌ ### What happened? At 09:26 UTC we deployed a release to our API Gateway service, which uses feature flags: configuration settings that allow us to enable or disable features without redeploying code. In this deployment there was a missing feature flag: the value was undefined in production and the code did not gracefully handle undefined feature flag values. The release had been tested extensively in our staging environment since November 20th 2025 with no issues, however the testing in staging did not take into account how an undefined feature flag value in production could have affected the release. Due to this testing overconfidence, we enabled an immediate global release, rather than a gradual rollout. The immediate global rollout caused the issue to have larger impact that it otherwise should have had. The team rolled-back a recent deploy relating to the Management API as precautionary step while they continued to investigate. This did not solve the issue. Once the offending commit was identified the API Gateway release was rolled back, resolving the issue. ‌ ### Fixing the root cause To guarantee that our code properly supports undefined feature flags, we now apply TypeScript's `Partial` utility type to the FeatureFlags interface. This ensures that every feature flag property is automatically marked as optional, eliminating the risk of runtime errors from missing values: ``` // Make all feature flags optional: enforced by type system type FeatureFlagPartial = Partial // Internal type that includes feature flags: only used by getFeatureFlags type EnvironmentInternal = Config & FeatureFlagPartial ``` ‌ ### What will we do to mitigate problems like this in the future? 1. **Feature Flag Resilience** - we have improved our API Gateway to ensure that we gracefully support undefined feature flag values. We are making the same changes to all systems across the platform. 2. **Improved Deployment Strategy** - we are enforcing changes to our Release Management process, so that global rollouts are not possible except in the explicit case case of an override due to a hotfix or security concern. All services will follow a gradual staged rollout. 3. **Enhanced Observability** - we are integrating additional API Gateway metrics and alerts into our monitoring stack. This work has been prioritized to ensure similar incidents are detected immediately. This will bring the API Gateway in-line with our standard for service monitoring. 4. **Fixing second order-effects** - during the incident, there were reports of BigQuery errors. This was a downstream effect: as more customers were logging in to check their logs and observability, we hit rate limits on our logging service. We are already in the process of migrating to a new logging backend that will prevent these errors in the future. ‌ ### To our customers To our customers: I'm sorry if this affected you. Supabase is the core infrastructure for millions of developers. This outage was avoidable, and the relaxed processes were unacceptable. Our focus as a company is to become the most reliable service available. This outage is our responsibility and we’ll use it as an important lesson for several areas of improvement. On behalf of the Supabase team - we’re sorry, and we’ll do better. Paul, CEO & cofounder

This incident has been resolved.

We rolled back a deployment to our API Gateway and we can see requests recovering. We will continue to monitor.

We are continuing to work on a fix for this issue.

We have identified issues with failing requests across a range of services and customer projects. Our Engineering team is working to resolve this now.

We are currently investigating this issue.

This incident has been resolved.

A fix has been implemented and we are monitoring the results.

Edge Functions are globally affected across all regions, and a fix is being rolled out.

We are currently investigating this issue.