Reading the cards

What each card means: overall health, the host gauges, per-service probes, proxy security, and the Supabase project.

Each card on the status board answers a different question. Here's how to read them.

The Host card

The Host card reports the server the board runs on. The numbers are read straight from the operating system, so they're real, not estimates:

  • Load · N CPU — the 1-, 5-, and 15-minute load averages, with a gauge showing the 1-minute load as a percentage of CPU capacity.
  • Memory — used / total, with a gauge of the used ratio.
  • Uptime — time since the server last booted.

The gauges are color-coded by pressure: green below 60%, amber 60–85%, red at or above 85%. A row of mostly-green cells is healthy.

The Proxy Security card

This card shows the live open-relay-abuse picture for the proxy server. It only appears when the proxy is reachable.

The header dot is green when traffic is clean and red when the proxy reports it's under attack. A badge shows the source-IP gate mode — enforce (refusing unknown source IPs) or shadow (logging only). The metric grid covers the last 60 seconds:

  • Abuse / min — abusive requests per minute.
  • Abusive IPs — distinct abusive source addresses.
  • Refused / min — requests the gate turned away.
  • Cap drops / min — requests dropped by the per-IP connection cap.
  • Active conns, Throttled IPs, Top IP conns — current pressure on the pool.
  • Devices gated — how many devices are bound over how many source IPs.

Note: This is the user-visible face of the proxy's source-IP gate, which protects the shared proxy from open-relay abuse. The mechanism is explained in Web proxy internals.

The Supabase Project card

This card reports our backend project specifically, not generic Supabase status:

  • Project meta — project status, region (we run in eu-west-1, Ireland), probe latency, and Postgres version.
  • Per-service health — Database, Data API, Auth, Realtime, Storage, and Pooler. Auth and Storage are proven live by public version probes; the rest come from Supabase's Management API and show as muted "needs token" when the board is running without that token (for example, on your laptop).
  • Affecting our project — scheduled maintenance and unresolved incidents from Supabase's public status page, filtered to our region.

A per-service card

Every service gets its own card with a status dot, a name, and a core badge for the two critical services. The badge on the right reads operational when healthy, or shows the failure (timeout, down, or a unit sub-state). The detail grid:

  • Latency — round-trip time of the health probe, in milliseconds.
  • HTTP — the status code the probe got back (— if it never completed).
  • Build — the deployed build number. A surprising value here is a sign of build drift.
  • Service uptime — how long the service has been running. Cloud-hosted services show Supabase Cloud instead.
  • Host — a link to the service's public hostname.

Heads up: A card can read unhealthy even when the HTTP probe succeeded — if the underlying service unit reports a bad state (for example, restarting), the card flags it. That's intentional: a service answering HTTP but flapping isn't really healthy.

See also

OverviewOverview