Supabase & Firebase Monitoring: Backend Uptime Guide

The pitch for a Backend-as-a-Service is simple: don't run your own backend. Use Supabase or Firebase, get auth, a database, file storage, realtime, and serverless functions in an afternoon, ship the app, and forget about infrastructure.

The catch is also simple: when something breaks, you can't fix it. You can't SSH into Firestore. You can't restart the Supabase auth service. The "infrastructure you don't run" is the same infrastructure that's currently down, and your only signal is a status page that updates ten minutes after your users start complaining.

BaaS adoption has exploded. Hundreds of thousands of products now run on Supabase or Firebase as their primary backend. And yet most teams monitor the BaaS the same way they monitor their app: a single /health ping that says everything's fine — right up until users can't log in, can't load data, can't upload a file, or hit a quota limit you didn't know existed.

This guide covers what to monitor on Supabase and Firebase backends so you catch outages, quota limits, auth flow failures, and slow queries from your application's perspective — not from the provider's status page.

Why BaaS Backends Need Their Own Monitoring Approach

A traditional self-hosted backend gives you control: you can ping your own database, watch your own connection pool, restart your own service. A BaaS takes that control away — and traditional monitoring loses signal along with it.

A few realities about BaaS monitoring:

You don't run it, but you depend on every layer. Auth, database, storage, functions, realtime — if any layer degrades, your app degrades. The blast radius of a BaaS incident is the entire backend.
The provider's status page lags. Supabase and Firebase status pages publish incidents minutes — sometimes tens of minutes — after your users feel them. By the time the status page goes red, you've already had complaints.
Quotas fail silently. Hit Firestore's 50,000 reads/day on the free tier? Reads start returning errors with no advance warning. Hit Supabase egress limits? New connections get refused. Your app doesn't crash — specific features just stop working.
Auth flows fail in ways /health doesn't catch. The auth service can be "up" but token issuance can be slow, refresh can be failing for a subset of users, or social login providers (Google, Apple, GitHub OAuth) can be in mixed state.
Region matters. Both Supabase and Firebase deploy regionally; an issue in us-east-1 doesn't show up on a eu-west-1 health check.
Cold starts on serverless functions. Functions that fire infrequently are slow on first invocation — your monitoring needs to distinguish "slow" from "broken."
Row-level security and security rules are easy to misconfigure. A schema change can break RLS in a way that returns 200 OK but with empty results.

Standard uptime monitoring catches "is the BaaS responding?" For BaaS specifically, that's barely a fraction of the failure surface.

The BaaS Dependency Surface

Before you can monitor your BaaS backend, you need to know what you actually depend on. The typical surface:

Authentication — sign-up, sign-in, OAuth provider callbacks, JWT issuance, token refresh, password reset
Database — primary data store (Postgres for Supabase, Firestore or Realtime DB for Firebase)
Realtime / subscriptions — websocket or long-poll channels for live updates
Functions / edge functions — serverless code (Supabase Edge Functions, Firebase Cloud Functions)
Storage — file upload, file download, signed URL generation
Hosting / CDN (Firebase Hosting only) — static asset delivery
Quotas and billing — read counts, write counts, egress, function invocations
Project / dashboard availability — separate from data plane; if the dashboard is down you can't change config, but the app keeps working

Monitor each of these as an independent dependency. A single overall "is Supabase up?" check tells you almost nothing useful.

Supabase-Specific Monitoring

PostgREST Data Endpoint

Supabase exposes your Postgres database through PostgREST at https://<project>.supabase.co/rest/v1/. Monitor it like any REST API:

Set up a check that hits a small known endpoint, e.g., GET /rest/v1/<table>?select=id&limit=1
Include the apikey and Authorization: Bearer <anon-or-service-key> headers — see Monitor Authenticated APIs With Bearer Tokens and Custom Headers
Validate the response body shape (an array of objects), not just a 200
Alert on response time > 1 second (PostgREST should be fast)

This single check catches database outages, PostgREST outages, and project-level issues simultaneously.

Supabase Auth

The auth endpoint sits at https://<project>.supabase.co/auth/v1/. The simplest health check is the public settings endpoint:

GET /auth/v1/settings — returns auth configuration; if this fails, auth is fully down
For deeper monitoring, run a periodic test sign-in with a dedicated monitoring account; alert if token issuance fails or takes > 2 seconds
Monitor OAuth provider callbacks separately — Google/Apple/GitHub each have their own uptime

See Login and Authentication Flow Monitoring for the full auth-flow pattern.

Realtime Channels

Supabase Realtime runs websockets at wss://<project>.supabase.co/realtime/v1/websocket. Monitor by:

Establishing a websocket connection, subscribing to a known channel, and confirming you receive a heartbeat within a few seconds
Watching connection drop rates from your application logs
Alerting if your client-side reconnect count spikes (often the first signal of regional issues)

Edge Functions

Each deployed function has its own URL: https://<project>.supabase.co/functions/v1/<name>. Monitor each critical function:

Hit a minimal "health" function (write a tiny health function that just returns {ok: true})
Track p50/p95/p99 latency separately — cold starts skew the average
Watch the deploy revision so you know which version is running

Storage

https://<project>.supabase.co/storage/v1/. Monitor:

A HEAD request to a known public object (cheapest possible check)
For private storage, a signed-URL generation + download flow
Alert on response time > 3 seconds (storage is sometimes slower than data)

Database Connection Pool (Direct Postgres)

If your app connects directly via the Postgres connection string (not through PostgREST), monitor connection pool utilization the same way you would for any Postgres — see Database Monitoring: MySQL, PostgreSQL, Redis, and Uptime. The pooler (PgBouncer) sits in front; saturation there will surface as connection refused errors.

Project-Level Quotas

Supabase free/pro tiers have monthly limits on:

Bandwidth (egress) — once exceeded, requests start failing
Database size — once exceeded, writes fail with a clear error
Storage size — same
Active monthly users — tracked but doesn't hard-fail

The Supabase dashboard surfaces these; set an internal monitor that fetches your project's usage via the management API and alerts at 80% of any quota.

Firebase-Specific Monitoring

Firestore

The hardest layer to monitor from outside, because Firestore has no public HTTP endpoint you can curl directly — it speaks gRPC over HTTPS with Google's auth.

Practical approach:

Build a tiny "canary" Cloud Function that performs a read against a known document and returns success/failure with timing
Monitor that function's URL with a public HTTP check
Track Firestore read/write count via Cloud Monitoring against your quotas
Alert on the canary function failing 3 consecutive times, or its latency exceeding 1 second

Firestore-specific failure modes worth tracking:

Index missing — a query that needs a composite index fails after a schema change
Security rules denying valid requests — usually after a rules deploy
Hot document contention — frequent writes to the same document throttle to ~1 write/sec
Quota exhaustion — particularly on the free/Spark plan

Realtime Database (legacy)

If you're still on Firebase Realtime Database (not Firestore):

GET https://<project>.firebaseio.com/.json?shallow=true — quick reachability check
Watch for "permission denied" responses suggesting rules issues
Monitor connection count if you're approaching the 200,000 concurrent connection limit on Blaze

Firebase Auth

Monitor via a canary Cloud Function that performs a sign-in or token refresh against a dedicated test user. Track:

Sign-in latency
Token refresh success rate
OAuth provider success rate (separately for Google, Apple, etc.)

Cloud Functions

Each function exposes an HTTPS trigger. Monitor:

A simple "health" Cloud Function with an HTTP check
Cold start latency (separately tracked)
Function-specific error rate from Cloud Monitoring

Two Firebase-specific failure modes:

Generation 1 vs Generation 2 functions have different cold-start and scaling behavior
Cold starts on lightly-used functions can be 5-10 seconds; alert thresholds need to account for this

Cloud Storage

A HEAD request to a public object
Signed URL generation latency for private files
Quota tracking (storage size + egress)

Firebase Hosting

Firebase Hosting is a CDN. Monitor:

Cache hit ratio (via Firebase console)
A canary URL with response time tracking
Certificate expiry (Firebase manages this but alert on certificate issues anyway)

See CDN Monitoring: Catch Edge, Cache, and Origin Failures for the underlying CDN monitoring patterns.

Monitoring From Your App's Perspective vs the Status Page

The single most important shift in BaaS monitoring: don't trust the provider's status page as your detection layer.

The status page is the provider's claim about availability. Your monitoring is your application's observed reality from the regions and request patterns that match your users. These two are often different.

Specifically:

Status pages lag — typically 5–20 minutes between an incident starting and the page going red
Status pages aggregate — they don't show you regional issues that affect only your customers
Status pages can miss problems entirely — degraded performance below the provider's incident threshold but above what your users tolerate

Your monitors must run from your users' regions, with your application's request patterns, with your application's authentication. See Multi-Region Monitoring: Why Location Matters.

A practical rule: if the status page says "all systems operational" but your synthetic checks are failing, trust your checks.

Cold Start Latency on Serverless Backends

Both Firebase Cloud Functions and Supabase Edge Functions cold-start. The first invocation after idle time can take 5–10× the warm time. For monitoring, this creates a noise problem:

A 5-minute uptime check on a low-traffic function will hit cold starts almost every time
That makes the function look slow when it's really just idle

Two approaches:

Keep functions warm — issue a tiny invocation every 60 seconds (your monitoring check itself can do this) so the function stays hot. Costs a few cents per month per function.
Separate cold-start tracking from p95 latency — log whether each request was a cold start (most platforms expose this in the request context), and alert on p95 excluding cold starts.

For user-facing functions that absolutely must be fast on first invocation, the warmth strategy is worth the cost. For internal or batch functions, just track them separately.

Quota and Usage Monitoring

Quotas are the silent killer of BaaS reliability. Some specifics worth alerting on:

Supabase

Egress / bandwidth — once exceeded, requests start failing. Alert at 80% of monthly quota.
Database size — alert at 80%; provides time to upgrade or archive
Storage size — alert at 80%
Active connections — pooler can run out of slots; watch via dashboard

Firebase

Firestore reads/writes/deletes per day — alert at 70% on free tier (where overage = failure)
Cloud Functions invocations and CPU-seconds
Cloud Storage egress — same pattern
Auth daily active users — relevant on Spark plan
Firebase Hosting bandwidth — particularly important during promotional events

Fetch usage data via the platform's management API (Supabase Management API, Google Cloud Monitoring API) on a daily schedule, and alert when any quota crosses thresholds.

Auth Flow Monitoring Specifically

Auth is the highest-stakes BaaS dependency. If users can't sign in, your entire product is functionally down — even if the database is healthy.

Run periodic full-flow auth checks:

Sign-in with a known credential (dedicated monitoring user)
Token refresh (use the refresh token from sign-in to get a new access token)
A simple authenticated request (verify the new token actually works against your data endpoint)

Track each step's latency separately. A slow sign-in often indicates upstream OAuth provider issues; slow refresh often indicates the auth service itself; slow authenticated requests indicate downstream services.

Alert thresholds:

Sign-in p95 > 2 seconds → warning
Sign-in p95 > 5 seconds → page
Any complete auth flow failure → page after 3 consecutive failures

For OAuth flows specifically, monitor each provider (Google, Apple, GitHub) independently. They fail independently; lumping them together loses signal.

Row-Level Security and Rules Failure Modes

This is the subtlest BaaS failure mode. Both Supabase (with Postgres RLS) and Firebase (with security rules) let you write declarative policies that determine which users can read/write which data.

Common patterns that break in production:

Schema change deploys but rules don't update — new columns are accessible, but rules don't cover them
Rules deploy that's too restrictive — valid requests now return empty results or permission errors
Test data with weak rules in production — security vulnerability hiding under the radar

Detection:

Monitor "expected non-empty" queries — if a known query for a known user normally returns 5 rows and now returns 0, that's a rules regression
Monitor permission-denied error rate — a spike usually means a rules deploy went wrong
Run a regression test suite of RLS/rules cases on every deploy — much higher leverage than runtime monitoring

Alert Thresholds That Work for BaaS

Tune for the noise level of these platforms:

Single check failure: log only
3 consecutive failed checks (3 minutes): notification to channel
5 consecutive failed checks: page on-call
p95 latency > 2× baseline for 10 minutes: notification
p95 latency > 4× baseline for 5 minutes: page
Any quota crosses 80%: notification (this is preventative, not urgent)
Any quota crosses 95%: page (you're about to start failing)
Auth-specific check fails twice: page (auth is too critical for the "3 consecutive" rule)

See Alert Fatigue: Notifications That Get Acted On for the principles.

Setting Up a Supabase / Firebase Uptime Check

A minimal but useful uptime check for Supabase:

GET https://<project>.supabase.co/rest/v1/healthcheck?select=id&limit=1
apikey: <anon-key>
Authorization: Bearer <anon-key>

Configure your monitor to:

Run every 60 seconds from at least two regions
Alert if response time > 1 second (a single-row select should be fast)
Validate response body confirms an array structure
Use a dedicated healthcheck table with a single row, with public read policy — separate from your application data
Use a dedicated monitoring API key scoped to read-only on the healthcheck table

For Firebase, deploy a small Cloud Function:

exports.healthcheck = onRequest({ cors: true }, async (req, res) => {
  const start = Date.now();
  const snapshot = await db.collection('_healthcheck').doc('canary').get();
  res.json({
    ok: snapshot.exists,
    latency_ms: Date.now() - start,
  });
});

Monitor that function's URL with the same pattern.

For more on per-endpoint API uptime patterns, see REST API Monitoring: Endpoints, Errors, and Performance. For broader provider-availability strategy, see Third-Party Dependency Monitoring: What You Don't Control.

Health Checks From Your App vs External Monitoring

Your application can also expose its own /health endpoint that proxies a check to your BaaS. This is useful because:

It catches issues from inside your app — including auth misconfigurations and connection-string problems
It's what your load balancer and orchestrator use anyway

But always have external monitoring as well. The internal /health view is blind to issues that occur between the public internet and your application. See Health Check Endpoints: /health, /livez, /readyz Guide for the contract design.

The right setup is layered:

External uptime monitor → public app URL (catches all-the-way-broken)
External monitor → BaaS endpoint directly (catches BaaS issues independently of your app)
Internal /health → tests app + BaaS together (catches misconfigurations)

BaaS Monitoring Checklist

For every BaaS-backed production app:

Database endpoint uptime check every 60 seconds, content-validated
Auth flow check (sign-in + token refresh + authenticated request) every 5 minutes
Realtime / websocket check (if applicable)
One uptime check per critical Edge Function / Cloud Function
Storage uptime check (HEAD on a known object)
Daily quota usage scrape with 80% and 95% alerts
Cold-start tracking separate from steady-state latency
OAuth provider checks (Google / Apple / GitHub) independently
Multi-region external checks from your users' regions
Regression test suite for RLS / security rules on every deploy
Application /health endpoint that includes a BaaS-dependency check
Provider status page subscribed (lagging indicator only)

How Webalert Helps Monitor BaaS Backends

Webalert is built for monitoring exactly the kind of authenticated, JSON-responding, latency-sensitive endpoints that Supabase and Firebase expose:

HTTP monitoring with custom headers — apikey and Authorization: Bearer for Supabase; bearer tokens for Firebase Cloud Functions
Content validation — Verify the response body shape, not just a 200
Response time alerts — Catch latency degradation before users feel it
Multi-region checks — Confirm BaaS reachability from every region your users come from
1-minute check intervals — Detect BaaS provider incidents within a minute
Multi-channel alerts — Email, SMS, Slack, Discord, Microsoft Teams, webhooks
Status page — Communicate to your users when the BaaS provider is degraded
5-minute setup — Add the endpoint, paste your key, set thresholds, and you're live

See features and pricing for details.

Summary

BaaS platforms move infrastructure out of your control — and out of the visibility your traditional monitoring depends on.
Monitor each layer of the BaaS dependency surface independently: auth, database, realtime, functions, storage, quotas.
Supabase and Firebase have different failure modes: PostgREST + Postgres for one, Firestore + Cloud Functions for the other; each layer needs its own canary.
Status pages lag your users' experience by 5–20 minutes. Trust your synthetic monitoring as the primary signal.
Cold starts on serverless functions create noise; either keep functions warm or track cold-start latency separately.
Quotas fail silently. Alert at 80% of any monthly quota; page at 95%.
Auth is the highest-stakes BaaS dependency; run full-flow auth checks every few minutes, alert aggressively.
Layer your monitoring: external BaaS check + external app check + internal /health that exercises the dependency.

The promise of a BaaS is "don't think about backend infrastructure." The reality is: think about it differently. The infrastructure is still there — you just monitor it from the outside in.

Monitor your Supabase or Firebase backend from your users' perspective

Start monitoring with Webalert →

See features and pricing. No credit card required.