Your app starts throwing connection errors, queries time out, or auth stops issuing tokens, and the first move is almost always the same: open a new tab, search "is Supabase down," and land on status.supabase.com. Ninety seconds later you are staring at a green board that says every component is operational, and the errors have not stopped.
That gap is not a bug in the status page. It is what a status page is for and what it is not for, and knowing the difference gets you to an answer faster than refreshing the tab.
What Supabase's status page actually tracks
Supabase's status page breaks the platform into components: Compute, API Gateway, Database, Storage, Auth, Connection Pooler, Management API, Edge Functions, Realtime, Analytics, and the Dashboard, each tracked separately per region (ap-northeast-1, eu-central-1, us-east-1, and the rest). That is a genuinely useful granularity: a Database incident in one region does not have to turn the whole board red, and if your project runs in us-east-1, the eu-central-1 row telling you nothing is exactly correct.
What the page does not tell you is how an incident gets onto it. Publishing a component as degraded or down is a decision, made by a person, after something has already been confirmed. Every status page shares that lag, not just Supabase's; we covered the general pattern in why "is it down" sites disagree. The practical result: if your project has been broken for ten minutes and the board is still green, that is not proof you are wrong. It might just be early.
The three places a "Supabase is down" feeling actually comes from
Before you file it as a platform incident, it is worth ten seconds each on three much more common causes, roughly in order of how often they turn out to be the answer.
1. Your own project, not the platform. The single most common cause of "Supabase seems down" is a problem scoped to one project: a paused free-tier project (Supabase pauses a Free-plan project after 7 days of database inactivity, and the first request after a pause just hangs for 10 to 30 seconds while it cold-starts, which reads exactly like an outage from the client), a connection pool exhausted by an unbounded number of serverless function instances each opening a new Postgres connection, an expired or rotated API key, or a migration that changed a table your app still queries under the old shape. None of these show up on any status page, because none of them are Supabase's problem.
Open your project's own logs first. The Supabase CLI does not ship a generic logs command (there is no supabase functions logs or supabase db logs); logs live in the Dashboard under Logs, split into API, Postgres, and Edge Function logs, filterable by time range, status code, and path, with the Logs Explorer running SQL over them for anything more specific than a quick scan. From the CLI, supabase inspect db locks and supabase inspect db long-running-queries catch a connection pool that is stuck or a query holding a lock past what your app expects, and supabase projects list confirms the project is not sitting paused in the first place. A specific error in any of these resolves the question immediately, usually faster than a probe from outside ever could.
2. A regional incident that does not affect your region. If you check the status page and see Database degraded in ap-northeast-1 while you run in us-east-1, that is not your incident. This is where the per-region granularity earns its keep: read the row for your own project's region, not the top-line banner.
3. An actual platform incident that has not been published yet. This is the case the status page structurally cannot help you with while it is happening. It only becomes visible once the lag closes.
What actually distinguishes case 3 from the other two
The only way to tell "an unpublished platform incident" apart from "your project has a problem" from outside Supabase's own dashboards is to measure something independent of both: a request from a location that is not your production servers, hitting a Supabase endpoint that is not scoped to your project.
That is what a direct probe check gives you that a status page and your own project logs cannot. The RealUptime Outages page for Supabase does exactly this: it probes Supabase's public REST API (api.supabase.com/v1/projects) on a real, unauthenticated request and cross-checks it against Supabase's own status page, from RealUptime's live regions, on a fixed interval, independent of any single project's configuration. If that endpoint is healthy while your project throws errors, the fault is almost certainly scoped to your project or your region, not the platform. If it is failing too, you have evidence for a platform incident before Supabase has published one, and a specific reading (which region, since when) to include when you open a support ticket.
This distinction matters because it changes what you do next. "The platform is down" means wait, and maybe queue writes locally if your app can tolerate it. "My project is broken" means the fix is in your own dashboard right now, and every minute spent refreshing status.supabase.com instead of checking your connection pool size is a minute your users spend on a broken app that Supabase cannot fix for you.
Watching your own Supabase-backed app, not just the platform
A platform status page, however good, answers "is Supabase up," never "is my app up." Those are different questions with different failure modes: your app can go down while Supabase is perfectly healthy (a bad deploy, a migration that broke a query, an environment variable that did not carry over), and a platform-level check will show green the entire time.
The fix is to monitor the thing your users actually hit, not the platform underneath it. On RealUptime Monitor, that means an HTTP check against your app's real URL (not Supabase's), from every live region, on the interval you choose; a TCP check if you connect directly to the Postgres instance over the pooler and want to know the moment the port stops accepting connections, independent of whether a query would succeed; and, for anything that runs on a schedule against your Supabase project (a cron job doing a nightly export, a queue worker consuming a Postgres LISTEN/NOTIFY channel), a heartbeat monitor that alerts on silence rather than on a failed request, covered in detail in our heartbeat monitoring guide. None of this requires access to Supabase's infrastructure or an enterprise support plan: it is a check pointed at a URL you already have, set up in a few minutes.
Getting notified without refreshing a status page
Everything above assumes you are checking by hand, in the moment. For a service your product genuinely cannot run without, that is still a step slower than being told. RealUptime Monitor's vendor watchlist add-on (available on any paid Monitor plan) lets you pick Supabase, along with any other vendor in the Outages catalog, and get an alert through your own channels, email, Slack, PagerDuty, or a webhook, the moment RealUptime's own probes confirm a watched vendor's outage opens, reopens, or closes. It is the same probe-measured data behind the public Supabase outages page above, routed to you automatically instead of requiring a manual check, and it never depends on a user report or the vendor's own claim: only a confirmed probe result triggers the alert.
That is a different tool from watching your own app (below), and worth keeping separate in your head: the watchlist tells you when Supabase itself changes state; your own app's checks tell you when your app stops working, regardless of whose fault it is.
The short version
- Green on status.supabase.com does not mean your project is fine; it means Supabase has not (yet, or ever, if it is project-scoped) confirmed a problem.
- Check your own project logs and dashboard first. Paused projects, exhausted connection pools, and stale API keys outnumber real platform incidents by a wide margin.
- Read the status page by your project's own region, not the top banner.
- For an independent, project-agnostic read during a live incident, a direct probe check like the Supabase outages page tells you whether the platform's core API is answering right now, from outside Supabase's own systems.
- For your own app's uptime, watch the app itself, not the platform it sits on. That is the check that catches your bad deploy at 2am, which no platform status page ever will.