# Supabase status

> Is Supabase down? Live status, uptime history, and per-region response times measured by our own probes every 2 minutes from five locations.

Published: 2026-08-21 | Canonical: https://yoping.me/status/supabase

## 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.

The live board - the current verdict, 24-hour, 7-day, and 30-day uptime, and per-region response times - is on the HTML page at https://yoping.me/status/supabase. Those numbers change too fast to repeat honestly in a static mirror, so where an answer below says "the board above", it means that page.

## 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.