API Monitoring Guide
Get alerted when your Supabase project has issues before your app can't read data, users can't log in, or your free-tier project silently pauses. Know the Supabase API status in real time, not 15 minutes later.
Supabase is the backend for countless apps — Postgres database, auth, realtime, storage, and edge functions, all behind one project domain at YOUR_REF.supabase.co. When the REST API (PostgREST) returns errors, Auth (GoTrue) starts rate-limiting, or your project hits its connection pool, your whole app breaks at once — and the global status page may say everything is fine.
This guide covers everything you need to monitor Supabase API status: which per-service endpoints to track, how GoTrue auth rate limits and connection limits work, how to catch a paused free-tier project, and what to do when a service goes down.
Supabase maintains a status page at status.supabase.com for platform-wide incidents. But because every project is its own isolated instance on its own subdomain, the most common failures are project-specific and invisible to the global status page.
External synthetic monitoring catches Supabase issues in 1-2 minutes, not 10-15. For a paused project or connection exhaustion, that's the difference between catching it before users do and finding out from an angry support ticket.
Supabase is several services behind one project domain. Knowing the path for each tells you exactly what to monitor and where a failure is.
PostgREST requires an apikey header. Use the anon key for monitoring public read paths — it respects Row Level Security and is safe to store. Never put the service role key in a monitor unless absolutely necessary, since it bypasses RLS.
Because all services share the project's compute and database, a single overloaded Postgres instance can take down REST, Auth, and Realtime together. Monitoring each path separately tells you whether it's one service or the whole project.
Each endpoint below tests a different Supabase service. Monitoring several lets you pinpoint whether it's the database, auth, functions, or a fully paused project.
GET https://YOUR_REF.supabase.co/rest/v1/
PostgREST root (with the apikey header). Confirms the REST API is up and your key is accepted. The cheapest signal that your project isn't paused. Make this your primary Supabase health check.
GET https://YOUR_REF.supabase.co/rest/v1/your_table?select=id&limit=1
Table read. Confirms the database itself is reachable through PostgREST and not just the gateway. Catches connection-pool exhaustion and RLS misconfigurations. Use a small table and limit=1 to keep it light.
GET https://YOUR_REF.supabase.co/auth/v1/health
GoTrue auth health. Confirms the Auth service is responding so logins and sign-ups work. Auth can degrade or rate-limit independently of the database, so monitor it on its own.
GET https://YOUR_REF.supabase.co/functions/v1/your-function
Edge Function. If you run business logic in Edge Functions, monitor a health route on one. Deno functions can fail on cold starts, timeouts, or deploy errors independently of the rest of the project.
GET https://YOUR_REF.supabase.co/storage/v1/object/public/bucket/health.txt
Storage object. If your app serves user uploads or assets from Supabase Storage, monitor a small public object to confirm the Storage API and CDN path are serving files.
Rate limit note: The PostgREST REST API isn't gateway-rate-limited by default, so light monitoring won't trip it — but it does consume a database connection, so keep table-read checks to limit=1 and reasonable intervals. Be more conservative on /auth/v1/ endpoints, which are IP-rate-limited around 30 requests per bucket.
Supabase's limits differ sharply by service. The real ceiling is often your database, not a published rate limit. Understanding this is essential for both a reliable app and accurate alerting.
Auth endpoints use a token-bucket algorithm per IP address, with buckets capped around 30 requests for operations like sign-in, sign-up, and OTP. Exceeding the bucket returns HTTP 429.
A login storm or attack can hit this and block legitimate users.
PostgREST isn't user-rate-limited at the gateway by default. The effective limit is your Postgres connection pool and compute size. Exhaust connections and queries queue or fail — so latency and 5xx on table reads are your real capacity signal.
Realtime caps concurrent connections, messages per second, channels, and joins per second. These are configurable per project and you can request increases. Because Realtime is a WebSocket, monitor it indirectly via an Edge Function health route or your app's realtime behavior.
A 429 on auth means IP rate limiting; rising latency then 5xx on REST means connection exhaustion or compute saturation; a hard, total failure across every endpoint usually means a paused project or a platform incident. A 503 points to the platform. UptimeSignal records status codes and response times so you can tell these apart.
Your app runs on Supabase. Monitor every service yourself.
Get alerted when PostgREST, Auth, or Edge Functions start failing — or when a free-tier project pauses — before your users can't log in. Free for 25 endpoints, checks every 5 minutes.
Monitor Supabase API free →Knowing the common failure patterns helps you configure monitoring that catches real problems and avoids false alerts.
After inactivity, free projects pause and every endpoint fails until you restore from the dashboard. Monitoring the PostgREST root catches this instantly — the fix is one click, but only if you know it happened.
A traffic spike or a client that doesn't release connections can drain the Postgres pool. Table reads slow down, then fail with timeouts or 5xx. Tracking response time on a table-read monitor warns you before it becomes a full outage — consider Supavisor/pooling if you see this often.
A login storm, credential-stuffing attack, or a buggy retry loop can trip GoTrue's per-IP token bucket and 429 your auth flow. Monitoring /auth/v1/health and watching for 429s on auth calls flags this early.
If you rotate the anon/service keys (e.g. after a leak) and forget to update a client, calls return 401. Your monitor catches the mismatch immediately so you can redeploy with the new key.
Deno Edge Functions can be slow on cold start or throw after a bad deploy. A dedicated function monitor with body validation catches a function that returns 200 but with an error payload — something a status check alone misses.
In the Supabase dashboard → Project Settings → API, copy your project URL (https://YOUR_REF.supabase.co) and the anon public key. You'll send the key as the apikey header.
Security tip: Use the anon key, which is RLS-protected and meant to be public. Keep the service role key out of monitors unless you must test a privileged path.
Sign up at app.uptimesignal.io and add a new HTTP monitor:
A failure here is the clearest signal that your project is paused or down.
Add a table-read monitor (database), /auth/v1/health (Auth), and a function/storage monitor as needed. Together they tell you which Supabase service is failing, not just that something is.
Route alerts where you'll act on them:
For production apps, use 1-minute checks (Pro plan) so a pause, connection exhaustion, or auth outage is caught within a minute instead of five. Frequent checks also keep a free-tier project from idling into a pause.
Configure your monitors to alert on these conditions:
For a table read, validate that the response is a JSON array (and not a PostgREST error object with a "message" field). For an Edge Function, check for an expected token in the body. Body validation catches a 200 that actually carries an error payload — a common Edge Function failure mode.
When monitoring alerts you to a Supabase problem, here's how to respond and limit the impact on your app.
Check your Supabase dashboard first (is the project paused?) and status.supabase.com for platform incidents. Determine whether it's a pause, auth rate limit (429), connection exhaustion, or an upstream outage.
If the project is paused, restore it from the dashboard immediately. To prevent recurrence, keep a low-frequency monitor running (which also keeps the project active) or upgrade off the free tier for a production app.
If reads are timing out, check for runaway queries or leaked connections, enable connection pooling (Supavisor), and consider scaling compute. Cache hot reads so the database isn't the single point of failure.
For auth 429s, add client-side throttling and CAPTCHA, and investigate whether it's organic load or an attack. Don't blindly retry into the rate limit — back off.
Update your status page so users know logins or data may be affected. If it's an upstream Supabase incident, link their official status post.
curl https://YOUR_REF.supabase.co/rest/v1/ -H "apikey: YOUR_ANON_KEY", and check Auth at /auth/v1/health. For continuous monitoring, set up UptimeSignal to poll every 1-5 minutes and alert you instantly when the status changes.
/rest/v1/, a table read like /rest/v1/your_table?select=id&limit=1, /auth/v1/health for Auth, and any Edge Function or Storage path you depend on. Each tests a different Supabase service that can fail independently.
/auth/v1/health for Auth, /rest/v1/ for the database REST layer, and your /functions/v1/your-function URL for Edge Functions. Realtime is a WebSocket, so the best proxy is a health route in an Edge Function plus tracking whether your app's realtime features work end to end.
UptimeSignal checks your endpoints from outside your network and catches errors before users do.
25 monitors free, unlimited for $10/month.
No password needed. We'll send a magic link.