What to watch ona Supabase project

8 min · you have a Supabase project · updated 23 August 2026

A Supabase project looks like one thing and is not. Behind the project URL sit a Postgres database, a REST layer, auth, storage, realtime and edge functions — and they fail independently. Auth can be down while the database is perfectly healthy, and a check on your app’s homepage will not distinguish them.

The failure modes that actually happen

Connection exhaustion. Easily the most common on smaller instances. A connection leak, or traffic growth without a pooler, and the database stops accepting new connections. Existing ones keep working, so the app degrades unevenly and confusingly.

A component down while others are up. Auth failing means nobody can log in; your marketing pages and any cached content still return 200 throughout.

The free tier pausing. Free projects pause after a week of inactivity. Fine for a side project, catastrophic if you did not know it applies to something with real users.

Disk filling. Postgres does not degrade gracefully when it runs out of space. This one is slow-moving and completely predictable, which makes missing it particularly annoying.

What Supabase tells you itself

The dashboard shows component health and resource usage, and there is a status page for platform-wide incidents. Both are pull, not push: they are excellent when you are already looking, and silent when you are not.

That is the gap. Not that the information does not exist — it is that nothing reaches you.

What Beaam watches

Connect with a Supabase personal access token. Beaam imports every project in your organization as a watchable service, then checks each project’s component health every minute:

REST or database component unhealthy → broken

Component health covers db, REST, auth, storage and realtime, so a component failing on its own is caught even while the rest of the project is fine.

Note what this is not: it is not a query against your data. Beaam holds a read-only token scoped to project health, never reads your rows, and cannot write.

Add a check that exercises your database

Component health tells you Supabase thinks the project is healthy. It does not tell you your application can successfully query it — a connection limit reached by your own app, or a broken RLS policy, will not show there.

Add an HTTP check against an endpoint in your app that performs a real read. Not your homepage: something that would fail if the database were unreachable. That is the difference between monitoring your provider and monitoring your product.

If you are on a paid tier

Watch connection count as a percentage of your limit rather than an absolute number, since the limit moves with your instance size. Beaam’s MongoDB integration alerts at 80% of the tier limit for exactly this reason; for Supabase, the equivalent early warning is worth wiring through your own instrumentation today.

A sensible setup

1. Connect Supabase — component health across every project.
2. Add an HTTP check hitting an endpoint that reads from the database.
3. If you run background jobs against it, connect that provider too.
4. Send a test alert and confirm delivery.

What this will not catch

Slow queries that have not yet become failures. Data correctness. RLS misconfiguration — which is a security problem, not an availability one, and worth a deliberate review rather than a monitor.

---