The status board is a single page that tells you, at a glance, whether every Busymate service is healthy — the dashboard, the backend, the MCP server, the proxy, the docs, and the board itself. It's live at status.busymate.net.
It's a separate app on purpose — its own process, its own server, its own hostname — so a dashboard outage can never take the status page down with it. When you most need to know what's broken, the status board is the thing still standing.
View the board
Open status.busymate.net. There's no login: the page and its health feed are public (coarse health only — never any of your data), so they stay reachable even when sign-in is the thing that's down.
The board refreshes every 7 seconds and pauses while the browser tab is hidden, so it's cheap to leave open in a background tab. The header shows how fresh the data is ("updated 3s ago").
The overall banner
The banner at the top is the one-glance verdict:
| Banner | Meaning |
|---|---|
| All systems operational | Every service is responding. |
| Partial degradation | A non-core service (MCP, Proxy, Docs, or Status) is down, but the core is up. |
| Major outage | A core service is down — the Dashboard or the Backend. |
Only the Dashboard and Backend count as core — that's the line between "degraded" and "down". A docs or MCP blip degrades; a backend blip is an outage. Below the banner, "N/M services responding" counts how many probes came back up.
What's on the board
Underneath the banner you'll find a set of cards:
- Host — the server's load, memory, and uptime.
- Proxy Security — live open-relay-abuse metrics from the proxy.
- Supabase Project — per-service health for our backend project.
- One card per service — status, latency, HTTP code, deployed build, and uptime.
The next page explains how to read each card.
Run it locally
The board is just a Next.js app, and it renders fine off-server:
cd web/status
npm install
npm run dev # http://localhost:3940Off the VPS, the external probes (Backend, MCP, Docs) run against the live hosts; the loopback probes (Dashboard, Proxy) only succeed if those services are also running locally; and host load/memory reflect your own machine.
Note: Want the design rationale — the probe model, the response shape, the fire-and-forget heartbeat that keeps history fresh? That's in Status board internals.