Uptime monitoring for Supabase-backed SaaS
Supabase gives you Postgres, Auth, Storage, Realtime, and Edge Functions behind a project URL. status.supabase.com tells you when the platform has an incident; it does not tell you whether your RLS policies, Edge Function deploy, or API key rotation broke production for paying users.
StillOnline runs external HTTP checks on a URL you control — usually your app’s /health that pings Supabase, or a dedicated Edge Function health route — and publishes a status page plus owner alerts through the StillOnline Telegram bot, Slack, or email.
Quick answer
Do not rely on status.supabase.com alone — it reflects platform-wide incidents, not your project's RLS or deploy state. Register a public HTTPS health URL (app or Edge Function) that returns 200 when your stack works end-to-end. StillOnline checks that URL every five minutes on Free (one project, one URL per pricing), hosts a status page, and alerts via the StillOnline bot. Edge Function cold starts can cause brief red checks — tune health logic accordingly.
What to check outside Supabase
| Signal | What it proves | StillOnline check? |
|---|---|---|
| status.supabase.com | Platform-wide outage | Inform incidents; not a substitute for your health URL |
App /health with DB ping | Your project + credentials work | Yes — primary pattern |
Edge Function /health | Functions deploy + secrets OK | Yes — watch cold-start false positives |
| Realtime websocket | Live channel delivery | Not a plain HTTP GET today — use app-level proxy health if critical |
Direct rest/v1/ without auth | Often wrong | Do not expose tables; use controlled health route |
See API-only SaaS checks when your product is mostly backend.
Step 1 — Design a Supabase-aware health route
Most indie SaaS add GET /health on the app server (Next.js, Remix, etc.) that runs SELECT 1 or a cheap Supabase RPC — see connecting to Postgres. Alternatively, deploy a tiny Edge Function that returns { "status": "ok" } when env vars and DB connectivity work.
Keep the handler under two seconds. Skip heavy queries on every probe hit.
curl -sS https://your-app.com/api/health
Edge Function cold starts may return slow responses once — if that flips StillOnline red too often, return 200 from a minimal function body and move DB checks to /ready instead. Details: health endpoint design.
Step 2 — Register in StillOnline
- Start free.
- New project → product name.
- HTTP check → your health URL, GET, 200, five-minute interval (Free).
- Add status page link to API docs — public status page guide.
Step 3 — Owner alerts
When Supabase or your function fails, you want a ping before support tickets arrive. Settings → Connect Telegram → StillOnline bot → Start — full walkthrough: Telegram uptime alerts.
Free: one owner channel. Pro / Ultimate: email, Telegram, and Slack together — pricing.
Supabase-specific pitfalls
| Problem | Solution |
|---|---|
| Platform green but your project paused | Health URL fails — expected; document billing or restore steps |
| Edge Function cold start | Lightweight /health without DB on cold path, or accept brief degraded |
| RLS blocks anonymous health | Use service role only server-side inside health handler, never in public response |
| Only monitoring marketing site | Monitor API health if product is backend — no-code guide |
Related guides
- Health check URL quickstart
- Next.js health check monitoring
- Neon and PlanetScale DB checks
- Telegram owner alerts
FAQ
Should StillOnline monitor status.supabase.com instead of my app?
No. Platform status does not prove your project, RLS, or Edge deploy works. Register your own health URL that hits your Supabase project the way production does — health quickstart.
Can StillOnline check Supabase Realtime over HTTP?
StillOnline runs HTTP GET checks. Realtime delivery needs an app-level health route that reflects whether your product’s live features work, or accept that HTTP health covers API availability only.
Does a cold-started Edge Function cause false StillOnline alerts?
It can, if /health is slow on first invoke. Use a minimal function, warmer schedule, or separate liveness without DB — see false positive tuning and health endpoint design.