Uptime Monitoring for Supabase and Firebase Apps

Q: How do I know if Supabase is down or if it's just my project?

Monitor your project's own endpoints, not just status.supabase.com. The platform status page reports infrastructure-wide incidents; it says nothing about your project being paused, your database hitting its connection ceiling, an expired JWT secret after a rotation, or a Row Level Security change that broke your queries. Point an external monitor at your project's REST URL (https://YOUR-REF.supabase.co/rest/v1/ with your anon key as a header) and at your app itself. When your monitor fails and the status page is green, the problem is on your side of the fence — which is most of the time.

Q: Why did my Supabase project stop working with no changes on my side?

If you're on the free tier, the most common cause is project pausing: Supabase pauses free projects after about a week without activity (as of 2026 — check their current policy), and a paused project returns errors to every request until manually restored. Side projects, demos, and internal tools that see bursty traffic hit this constantly. An external monitor checking every few minutes both detects the pause immediately and — usefully — counts as activity, which tends to keep the project awake in the first place.

Q: How do I monitor Firebase Cloud Functions and Firestore?

Give yourself an HTTP surface to check: expose a small health endpoint as an HTTPS Cloud Function that performs a bounded Firestore read and returns 200/503, and monitor that. It verifies your functions deploy, your Firestore rules allow the service path, and the project is billing-healthy, all in one probe. Monitor your Firebase Hosting site separately with a keyword assertion — Hosting outages are rare, but broken deploys that ship a blank index.html are not. Scheduled functions get the heartbeat treatment: ping a unique URL on success, alert on silence.

Q: Can a Supabase or Firebase app be broken while returning 200s?

Constantly — it's the signature BaaS failure. A Row Level Security policy change or Firestore security-rules deploy that's too strict doesn't return errors to your monitoring; it returns empty result sets with clean 200s while every real user sees a blank app. Keyword assertions are the defense: monitor an endpoint whose correct response contains data that only a working policy path returns — a known public row, a field name from a seeded record — so the empty-but-200 response fails the check.

Q: Should I monitor the platform status pages too?

Yes, as context rather than as your alarm. Your own monitors tell you that something is wrong seconds after it breaks; the status page tells you whether it's them or you, which changes your response — you can fix a paused project or a bad rules deploy, but you can only wait out a platform incident (and update your own status page). CronAlert can watch status-page feeds as ordinary monitors with keyword assertions, and our third-party dependency guide covers the pattern.

Supabase and Firebase sell the same beautiful promise: the backend is somebody else's problem. Database, auth, storage, functions — managed, replicated, professionally operated. And the promise is mostly kept, which breeds the failure mode this post is about: teams who never monitor their BaaS-backed app at all, because "Google runs it" — and then discover that the platform being up and your app working are two very different claims. Your project can be paused while status.supabase.com glows green. Your security rules can lock out every user while every health metric Google exposes reads perfect.

The division of labor is the key insight: the platform monitors their infrastructure; nobody but you monitors your project — its endpoints, its rules, its quotas, its billing state, its deploys. This guide covers that half: what actually breaks in Supabase and Firebase apps, and the small set of external checks that catch it.

The fence: platform status vs your project

Every BaaS failure lands on one side of a fence. Their side: regional outages, API-wide degradation, the incidents that make status pages orange. Your side: paused projects, exhausted quotas, connection ceilings, rules and policy mistakes, broken deploys, expired keys. The platform's status page only ever reports their side — and the overwhelming majority of "my app is down" moments live on yours. That's why the core setup is always: monitor your endpoints first, and treat the status page as a diagnostic input that tells you which side of the fence to look at. When your monitor is red and their status is green, you already know where to dig.

Monitoring a Supabase-backed app

The REST endpoint. An HTTP monitor on https://YOUR-REF.supabase.co/rest/v1/ with the apikey header (CronAlert supports custom request headers) verifies PostgREST is answering for your project. Better: query a known public table and assert on a value it must contain — see the RLS section below for why.
Auth. /auth/v1/health answers for the GoTrue service on your project — worth its own check if login is your front door. Our identity provider monitoring guide covers what breaks when auth degrades while everything else stays up.
Your app itself. The page or API route that real users hit first, with a keyword assertion on content that only renders when the Supabase calls succeeded.
Edge Functions. Each critical function gets a monitor on its invoke URL; a bounded-work health function is the cleanest probe.

The free-tier pause is its own failure mode. Supabase pauses free-tier projects after roughly a week of inactivity (policy as of 2026 — verify current terms), and a paused project fails every request until someone clicks restore. Demos, portfolio projects, and internal tools with bursty usage hit this on exactly the day someone important finally looks. An external monitor solves it twice over: you're alerted the moment a pause (or anything else) breaks the project, and the steady trickle of checks is itself activity that keeps the project warm. A 3-minute-interval monitor on CronAlert's free plan is a fitting guardian for a free-tier project.

Watch the connection ceiling too. Small Supabase instances have modest Postgres connection limits, and serverless frontends (a Vercel function per request, each opening a connection) exhaust them fast. The symptom is intermittent errors under load with instant recovery — flapping monitors plus a response-time ramp. Use the pooler (pgBouncer/Supavisor) endpoints, and treat monitor flapping as the signal it is; the same stall pattern appears in our Postgres monitoring guide.

Monitoring a Firebase-backed app

Give yourself an HTTP surface. Firestore's SDK-first design means there's no natural URL to probe — so make one: a tiny HTTPS Cloud Function that does a bounded Firestore read and returns {"status":"ok"} or a 503. One probe verifies functions deploy and run, service-path rules, and billing health. It's the same twenty-line health endpoint we build in every framework guide, hosted serverlessly.
Firebase Hosting. Rarely down platform-side, regularly "down" deploy-side: a build that ships a blank index.html serves perfect 200s. Keyword assertion on real page content — the static site guide's deploy-verification layer applies verbatim.
Scheduled functions. A onSchedule function that stops running (failed deploys, exhausted retries, billing suspension) is invisible to HTTP checks. Heartbeat it: ping a unique CronAlert URL as the last line after verified success — silence alerts. The serverless monitoring guide covers the wider pattern.
Cold starts. Functions that idle scale to zero; the first request pays seconds of startup. Your monitor's response-time data tells you what real first-visitors experience — and periodic checks keep hot paths warm as a side effect, same as the IIS trick in our ASP.NET Core guide.

Billing state is a single point of failure. A lapsed card on a pay-as-you-go Firebase project (or a Supabase org) doesn't degrade gracefully — services stop. It's rare, it's total, and it's exactly the kind of thing an external monitor catches at 6 AM instead of a customer at 9.

The 200 that lies: rules and policies

The signature BaaS outage isn't an error — it's an empty success. A Row Level Security policy tightened during a security pass, or a Firestore rules deploy with an overlooked allow read condition, doesn't fail your requests: it filters them to nothing. Every query returns 200 OK with zero rows; every user sees a blank app; every naive monitor stays green. This is the sharpest version of this series' recurring lesson — status codes lie — because here even the platform's internal metrics look healthy.

The defense is a keyword assertion on a response that only a working policy path can produce: a known value from a seeded public row, a field name that only appears when data actually flows. Rules deploys are exactly the moment things break, so the assertion doubles as a post-deploy smoke check: ship rules, watch the monitor, and know within one check interval whether you just locked everyone out.

A concrete CronAlert setup

Supabase: REST endpoint with apikey header + keyword assertion on seeded data (Pro), /auth/v1/health, your app's front door, and each critical Edge Function. Free-tier projects: the monitor is also your anti-pause keepalive.
Firebase: a health Cloud Function with a bounded Firestore read, Hosting with a content assertion, and a heartbeat per scheduled function (Pro).
Both: SSL monitoring rides along free; add the platform status pages as keyword-asserted monitors for them-or-us context (third-party dependency guide).
Response-time thresholds on the health probes — cold-start regressions and connection-pool stalls both announce themselves as latency first (thresholds guide).
Alert channels: email, Slack, Discord, Teams, Telegram, PagerDuty, Opsgenie, Splunk On-Call, webhooks, or PWA push.

A typical Supabase or Firebase app needs 4–7 monitors — inside CronAlert's free plan (25 monitors, 3-minute interval, SSL included), with keyword assertions and heartbeats arriving at Pro for $5/mo. Create a free account and the first check takes about a minute.

Frequently asked questions

How do I know if Supabase is down or if it's just my project?

Monitor your project's endpoints; read status.supabase.com for context. Monitor red + status green = your side of the fence (pause, quota, rules, keys) — which is the common case.

Why did my Supabase project stop working with no changes on my side?

On the free tier: probably paused for inactivity. An external monitor detects it instantly, and the checks themselves usually prevent it by keeping the project active.

How do I monitor Firebase Cloud Functions and Firestore?

Expose a health HTTPS function with a bounded Firestore read, monitor Hosting with a content assertion, and put heartbeats on scheduled functions.

Can a Supabase or Firebase app be broken while returning 200s?

Yes — RLS and security-rules mistakes return empty 200s, not errors. Keyword assertions on data only a working policy returns are the fix.

Should I monitor the platform status pages too?

As context, not as the alarm: your monitors detect; the status page attributes. Watch feeds as ordinary keyword-asserted monitors.

Monitor your half of the deal

Supabase and Firebase hold up their half impressively well — which is exactly why the outages that reach your users almost always come from the half nobody's watching: your project, your rules, your quotas, your deploys. Four to seven monitors close the gap, free. Create a free CronAlert account and point the first one at your project's REST endpoint in the next five minutes.