Status page

• Headline: "All systems normal", "N services down", "N services degraded" or "Status unknown" (nothing checked in the last 15 minutes), and when the last check ran. Checks run every 5 minutes.
• Services, one row each: the name, the tools that depend on it, the state word, the 90-day uptime, and a bar of 90 cells (oldest left, today right). A cell's colour is how long the service was out that day, as Statuspage and Better Stack shade theirs (since 2026-10-02): red for an hour or more down, amber for less than an hour down or half an hour or more slow, green otherwise, grey with no checks. Each check stands for five minutes. Hovering a cell (tapping one on a phone) opens a tooltip with the date, the day's state ("No downtime", "Partial outage" for under an hour down, "Major outage" for an hour or more, "Degraded" for slowness only, "No data" before checks began) beside a dot in its colour, and the figures ("99.4% up · 5 min down"). It is the workspace's tooltip surface, not the browser's title popup (since 2026-10-02), and near either end of the bar it hangs inward so it stays on the card. Until 2026-10-02 any single down check turned the whole day red, so a five-minute blip looked like an outage on a service that was long back up.

Days are UTC. In Australia the last cell ("Today") is still yesterday evening until 10:00 local time, so an outage from last night sits in it even when the row reads Up. A red last cell with Up beside it means it was out for an hour or more earlier that UTC day and is back, which is how other status pages show a resolved outage too.

• Incidents · 30 days: one line per outage, not per check and not per service: the services that fell in the same cron run are named together ("Conversion API · Conversion queue · Down"), with when it started and how long it lasted (or "Ongoing"). A service that drops again within 15 minutes of coming back reopens its incident rather than adding another. At most 50 are kept on the page.

The states: Up; Degraded (reachable but slow, over 3 s, rate limited, or refusing our key); Down (not answering, or a provider balance too low for the tool to run); Unknown (not checked in 15 minutes: the cron is not running, or the service has never been checked).

Top right of the app's bar, before the help mark: green when everything is up, amber when something is degraded, red when something is down, grey when nothing is known. Hovering it names what is not up; pressing it opens /status. It asks the API once the page is idle and every five minutes while the tab is visible. Hidden on phones.

Every status cron run posts what changed to the owner's #watchdog Discord channel (1554837408476962876), one message per run at most, linking /status. Nothing is posted while nothing changes.

• Down: at once (each probe already tries twice inside the run). "🔴 Imagine Pro · Down · balance".
• Degraded: only after two runs in a row, so one slow answer stays quiet.
• Worse: degraded to down.
• Still down: a reminder every six hours, with when it started.
• Back: after two up runs in a row, with how long it was out. A service that comes up for one run and drops again is never announced as back, so a flapping service posts once, not every five minutes.

The ops-alerts cron (ops-dashboard.md) posts to the same channel; it leaves out the four outages this one covers (WinAPI down, worker offline, Meshy or Tripo empty) and adds "Status checks · Stopped" when nothing has been written here for 20 minutes. Since 2026-10-07 the same cron ends with the account-sharing sweep (security.concurrent_use, profiles-and-verification.md); nothing on this page changed.

Is X down? Open /status. Red or amber on the row means the check saw it; the bar shows whether it is new. Imagine showing Down with everything else green usually means the provider balance is low (the credits doc, "Service Unavailable").

The page says Status unknown. The cron has not written a check in 15 minutes: the Vercel cron is not running or the route answers 401 (no CRON_SECRET). Staff: /ops and the Vercel cron log.

The support bot shows Unknown. It has never written a heartbeat (the bot has not been restarted since 2026-10-01), or the row is missing. Down means it has not beaten for ten minutes.

The support bot shows Down or Degraded but it is online in Discord. The heartbeat is a call from the bot to the database, so Down means the bot cannot reach the database or the site, not that it has left Discord. The gateway connection stays open, so the bot still looks online, but anything that needs the database or the site (support answers, tickets, role sync, the games) fails at the same time. On 2026-10-02 (from about 02:20 UTC) the cause was DNS: the box asked only Vultr's resolver 108.61.10.10, which answered SERVFAIL for zoov.dev, and so for db.zoov.dev whenever its cached answer ran out. The bot's log filled with getaddrinfo EAI_AGAIN db.zoov.dev. Fixed the same day by pointing the box at 1.1.1.1 and 8.8.8.8 (winapi Actions > Box inventory, input dns). To check again, run Box inventory: its "Network and the bot's outbound calls" step prints the bot's network errors, which DNS servers the box asks, and a three-round lookup of zoov.dev, db.zoov.dev and others against them, 1.1.1.1 and 8.8.8.8.

Why is a day amber when nothing was down? A check that day answered slowly (over 3 s) or was rate limited. Degraded, not down; uptime does not count it against the service.