/ use-cases / monitor-supabase-project
How to monitor your Supabase project
A Supabase project is REST, Auth, Storage and Realtime under one ref, not one service. Here is what to check separately and how to set it up.
Why Supabase's own signals are not uptime monitoring
A Supabase project is not one service behind one URL. It is Postgres plus a handful of
independently running pieces in front of it — PostgREST for the REST API, GoTrue for Auth,
Storage, Realtime, and Edge Functions if you use them — each exposed under the same project
subdomain but at its own versioned path: /rest/v1/ for REST, /auth/v1/ for Auth,
/storage/v1/ for Storage, /realtime/v1/ for Realtime. That routing layout is how Supabase's
own self-hosting documentation describes the gateway in front of these services, and it is the
same path scheme a hosted project answers on. Nothing in Supabase's own tooling watches all of
those paths together and reports "your project is up" as a single fact.
status.supabase.com is the closest thing to a status page Supabase runs, and it answers a different question: it tracks the health of Supabase's own infrastructure, broken down by component — API Gateway, Auth, Database, Connection Pooler, Realtime, Storage — and by region. None of that is scoped to your project. A database that is overloaded, a Row Level Security policy that rejects every request, a project that has simply run out of something it needs — none of it moves a platform-wide status page, which can read fully green while your project does not answer at all.
Free-tier projects add a failure mode with no equivalent on paid plans: Supabase's documentation says a project on the Free plan may be paused after a 7-day period of low activity, staying paused until you restore it from the dashboard or move to a paid plan exempt from this. From the outside — which is where an uptime check sits — a paused project and a crashed one look identical: both simply stop answering requests.
The dashboard's Security Advisor and Performance Advisor are worth running, but they are review tools invoked against your schema and query patterns — a table with Row Level Security disabled, a slow query pattern. Neither is a live signal: you have to go look at them, and they say nothing about whether the project was reachable an hour ago.
What is worth monitoring
The useful frame for a Supabase project is that it is several independently reachable endpoints sharing one project ref, not one target — and treating it as one target hides exactly the failures worth knowing about first:
- The REST endpoint (PostgREST) at
https://<project-ref>.supabase.co/rest/v1/— the path most apps actually call on every read and write. It answers 401 without a validapikeyheader, so a check against it needs the anon (publishable) key attached, not just a bare request. - The Auth endpoint (GoTrue), checked on its own rather than assumed to track REST. Supabase's
own troubleshooting docs point at
GET /auth/v1/health(again with anapikeyheader) as the documented way to confirm Auth is answering and read back its version. REST and Auth are separate processes behind the same subdomain — a bad Auth hook or an exhausted email-rate limit can break sign-in while reads through REST keep working fine, and the reverse is just as possible. - The Storage endpoint at
/storage/v1/, if the project serves files through it and that is not already implied by a passing REST check. - Any custom domain pointed at the project, since its DNS and registrar sit outside Supabase and can drift with nothing surfacing in the Supabase dashboard, plus the TLS certificate on that domain checked on its own — an HTTP check that only confirms the certificate is currently valid will not warn you before it is close to expiring.
Be honest about what an unauthenticated HTTP check cannot tell you, too. Supabase's shared connection pooler, Supavisor, sits between clients and Postgres with separate session and transaction modes on separate ports, built for exactly the kind of connection churn a serverless app produces. A REST check answering 200 tells you PostgREST could reach the database at that moment — it says nothing about pool headroom, and a pool problem is a distinct failure from the project not existing. Don't read more into a green check than it earned.
And do not reach for a service_role key to make a check "more thorough." Supabase's own documentation is direct that a secret (service_role) key bypasses Row Level Security entirely and grants full project access, and its guidance is not to put that key anywhere outside a trusted backend. A monitoring check has no legitimate use for that access — confirming the project answers only needs the anon key, which is what it is for.
How to set it up in Fettle
- Create an API key with write scope from Settings → API Keys, or add monitors straight from the dashboard.
- Add an HTTP monitor against the REST endpoint,
https://<project-ref>.supabase.co/rest/v1/, with a custom request header carrying the anon (publishable) key — Fettle's HTTP monitor config accepts arbitrary request headers for exactly this kind of authenticated check. - Add a second HTTP monitor against the Auth health path,
https://<project-ref>.supabase.co/auth/v1/health, with the same header. Two monitors, not one, because the point is knowing which service actually broke. - The REST monitor from step 2 looks like this from the API:
curl -s -X POST https://api.fettle.sh/v1/monitors \
-H "Authorization: Bearer fettle_your_key_here" \
-H "Content-Type: application/json" \
-d '{
"name": "Supabase REST",
"type": "HTTP",
"target": "https://your-project-ref.supabase.co/rest/v1/",
"interval_seconds": 60,
"timeout_seconds": 10,
"regions": ["eu-central", "us-east"],
"config": {
"request_headers": { "apikey": "your-anon-key" }
}
}'
interval_seconds has a plan floor and regions a plan cap. Try a check against your own
project's REST or Auth URL, without creating anything, on the
multi-region check tool first. The full walkthrough for creating a
key and reading results back is in the quickstart guide.
Prefer an MCP-aware client to raw curl? Point it at the same account with this one-liner:
{
"mcpServers": {
"fettle": {
"url": "https://api.fettle.sh/mcp",
"headers": { "Authorization": "Bearer fettle_your_key_here" }
}
}
}
Which alerts to wire
Two monitors that fail independently carry more information than one that just says "Supabase is down." A REST monitor failing while Auth stays up points at the database or PostgREST; an Auth monitor failing while REST stays up points first at GoTrue itself or its configuration — an email-rate limit, a broken auth hook — since REST is already proving the database reachable. Fettle sends alerts by email, Slack, Telegram or a generic webhook — wire whichever channel your team already gets paged on for production incidents, keeping REST and Auth as distinct alerts so the first line of the page names which service to look at.
Two habits keep it from becoming noise. First, use a maintenance window around planned schema migrations or a deliberate project pause, so the gap does not fire a false alert on a monitor still watching from outside. Second, if the project backs a public-facing app, put a status page in front of these monitors — Supabase's own status page stays green through an outage specific to your project, so your users need somewhere else to check. How many monitors, regions and status pages come with each plan is on the pricing page.
Questions
- Does Supabase's own status page tell me if my project is down?
- No — status.supabase.com reports on Supabase's own platform components, such as the API Gateway, Auth, Database and Connection Pooler, broken down by region. It tracks the health of Supabase's infrastructure, not any single customer's project.
- What happens to my project if I'm on the free plan and it goes quiet?
- Supabase's own documentation says a project on the Free plan may be paused after a 7-day period of low activity, to save server resources, and stays paused until you restore it from the dashboard. From outside, a paused project looks the same as one that is down.
- Should I put my Supabase service_role key in an uptime check?
- No. Supabase's docs are explicit that a secret (service_role) key bypasses Row Level Security and must never be exposed outside a trusted server. A check only needs to see a 200, so the anon (publishable) key is the right one to use.
Start monitoring in a minute
The free plan checks up to 20 monitors as often as every 2 minutes from 2 regions, and emails you when one breaks. See pricing for the paid intervals, or follow the quickstart to do it from the API.