Supabase incident on February 12, 2026
Published February 13, 2026 — Author: Paul Copplestone
On February 12, 2026, at 21:12 UTC, Supabase experienced a major outage affecting all services in the us-east-2 (Ohio) region. The outage lasted 3 hours and 42 minutes, with full service recovery at 00:54 UTC on February 13.
During this period, customers with projects in us-east-2 were unable to access their Postgres databases, Auth, Data APIs, Edge Functions, Storage, Realtime, and any other Supabase service in that region.
We apologize for this outage. We know how much our reliability matters to the businesses that depend on us, and we did not meet that bar here. Below is an account of what happened, how it happened, and the concrete steps we are taking to make sure it does not happen again.
Root Cause
A newly deployed internal monitoring service inadvertently enabled AWS’s VPC Block Public Access feature at the regional level in us-east-2, blocking all internet gateway traffic across every VPC in the region. The issue stemmed from insufficient safeguards in our infrastructure deployment pipeline.
Impact Scope
All Supabase customers with projects in us-east-2 were affected, including dashboard operations, database connections, authentication, storage, and real-time services. Connections via VPC peering and private networking remained unaffected.
Resolution Timeline
The investigation took 3 hours and 42 minutes due to multiple factors: alarms on shared services in different regions diverted attention, additional networking changes obscured the root cause in CloudTrail logs, pre-production environments lacked full parity with production, and initial response lacked appropriate infrastructure team representation.
The outage was resolved by rolling back the deployment, which removed the regional block and restored normal network connectivity.
Remediation Steps
Immediate actions: Audited all regions to confirm VPC Block Public Access was disabled and deployed AWS Organizations Service Control Policies to prevent such modifications.
Near-term safeguards: Implemented blocklists for dangerous resource types in Infrastructure-as-Code and improved access controls for audit log inspection.
Structural changes: Isolating non-customer-facing services to separate AWS accounts, adding continuous external connectivity probes, achieving full production-preproduction parity across regions, establishing faster incident coordination protocols, and developing cross-region failover capabilities through Multigres.
Communication Issues
We also identified significant gaps in how we communicated during the incident: delayed incident announcement, missing dashboard notifications due to earlier changes, slow component-level status updates, infrequent status page updates lacking context, and delayed social media communication. We are committing to rebuilding our notification systems and integrating social media into our incident response procedures.