Supabase status

How we check Supabase

We watch supabase.com from all five of our probe regions, every 2 minutes. A region that sees a failure does not make this page say "down" on its own: a second region has to agree first, the same confirmation rule every YoPingMe monitor uses.

A hosted Supabase project answers on its own per-project hostname behind its own keys, so there is no public endpoint that represents every customer's database. We watch Supabase's own platform host instead, which is an honest signal about the company's infrastructure and explicitly not a measurement of your individual project.

What is Supabase?

Supabase packages Postgres with the pieces most applications need around it: authentication, an auto-generated API over your tables, file storage, realtime subscriptions, and edge functions. The pitch is that a team gets a real relational database rather than a proprietary one, with the surrounding services already built, and the database remains ordinary Postgres underneath, which is what makes the tradeoff attractive to people who expect to outgrow the convenience layer eventually.

That composition is the first thing to understand during an incident. Supabase is several services sharing a project, and they fail independently. Authentication can be degraded while queries run normally. Storage can be slow while auth is fine. Realtime subscriptions can silently stop delivering while every other part of the product behaves. An application that depends on all of them will show a partial failure that is genuinely confusing to describe, because most of it works. The component breakdown on the official status page is more useful here than any single verdict, including ours.

The second thing worth knowing is that individual projects fail far more often than the platform does, and for reasons that have nothing to do with Supabase's health. Free-tier projects pause after a period of inactivity and need to be resumed, which surprises people returning to a side project after a quiet month. Projects live in a specific region, so an incident affecting one region leaves everyone else unaffected and produces contradictory reports. Keys rotated during a security tidy-up break every client that was not updated. None of these will ever appear on a status page, and all of them present as the application being down.

Connection limits deserve particular attention because they catch teams at exactly the wrong moment. Postgres allows a bounded number of concurrent connections, and serverless architectures are unusually good at consuming them, since every concurrent function invocation may open its own. Under light traffic nothing goes wrong. Under a spike, the database starts refusing connections while remaining entirely healthy, and the application logs fill with errors that read like an outage. Using the connection pooler rather than direct connections is the accepted fix and worth doing before the traffic arrives rather than during it.

The last category is performance, which is a database problem rather than a platform one. Row level security is the Supabase-specific version: policies are evaluated per row, so a policy that is cheap on a small table can become the dominant cost as the table grows, turning a fast query into a slow one with no change to the query itself.

Frequently asked questions

Is Supabase down right now?

Check the board above; it reflects our own probes against Supabase's platform from all five of our regions, refreshed every couple of minutes. Note that this measures the platform rather than your specific project, which lives on its own hostname in its own region.

My Supabase project is unreachable but this page shows Supabase up. What now?

Check your project's own state in the Supabase dashboard first, because projects fail individually far more often than the platform does. A free-tier project paused after inactivity, a database that hit its connection limit, a project in a region having a bad day, or an anon key rotated during a recent change will all take your application down while Supabase itself is healthy.

Why do I get connection limit errors under load?

Because Postgres has a finite number of connections and serverless functions are very good at exhausting them. Each function invocation that opens its own connection holds one until it closes, and a traffic spike opens far more than a long-running server ever would. Connecting through the pooler rather than directly is the standard fix, and it is the first thing to check when errors appear under load but never in testing.

Does a Supabase incident affect auth, storage and the database together?

Not necessarily. Supabase is a set of services around a Postgres database, including authentication, storage, realtime, and edge functions, and they can degrade independently. Sign-ins failing while queries succeed is a normal pattern rather than a contradiction, and the component breakdown on Supabase's own status page is the place to see which piece is affected.

My queries are slow but nothing is down. Where should I look?

Look at your own database before the platform. Missing indexes, a query plan that changed as tables grew, row level security policies evaluated per row on a large result set, and connection pool exhaustion all slow things down without any incident occurring. The query performance view in the Supabase dashboard reports the slowest statements, which is a faster path to the cause than any status page.