Platform status

/status answers one question—is the platform working, or is it just you—and answers it without asking who you are. No account, no sign-in. That's deliberate: the times you most need it are the times signing in is the thing that's broken.

Finding it

You shouldn't have to remember the address. It's linked from the footer of every page—including the signed-out ones—and again in the sign-in form's own copy, under Can't sign in? Check platform status.

Which build you are looking at

The same footer stamps the running build beside the Status link: the commit it was built from, and how old that build is.

The age is the half worth reading. A sha answers which build without answering whether it's the one that was just deployed—so if a change you expect is missing, the footer is the first place that says whether the deploy landed at all.

Operators get one thing more: the sha is a control (dotted underline) rather than plain text, and opens the build panel — the branches and merges behind that commit.

What it tells you

A headline, then four services, each with a state. That's the whole page. The services are groupings, not machines—the platform has considerably more moving parts than four, and which one broke isn't a useful thing to hand a reader.

The headline rolls all four up: All systems operational, Degraded performance, Partial outage, or—only when everything is down at once — Major outage.

What this page leaves out, on purpose, is why, or what the state means for you. No cause, no component names, no advice, no estimate. If "Builds & deployments" is down, new versions aren't going out and the page won't elaborate. That's not coyness for its own sake: a public page that narrates which internal subsystem is failing is telling everyone, not just you.

Last checked

The reading is cached for up to 30 seconds, and the page prints the timestamp it was actually taken (UTC) rather than claiming to be live. If you have just been told something is fixed, wait out the half-minute before believing the page over the person who told you.

For an uptime monitor

/status.json is the same answer as JSON, public and cacheable (Cache-Control: public, max-age=30).

{
  "status": "down",
  "headline": "Partial outage",
  "checked_at": "2026-08-05T16:07:35+00:00",
  "revision": "a1b2c3d",
  "services": [
    { "id": "control-panel",  "name": "Control panel",        "status": "ok" },
    { "id": "deployments",    "name": "Builds & deployments", "status": "down" },
    { "id": "hosting",        "name": "Application hosting",  "status": "ok" },
    { "id": "live-updates",   "name": "Live updates",         "status": "ok" }
  ]
}

status is ok, degraded or down—the worst of the services, so alerting on that one field is enough. Service ids are stable; name is prose and may be reworded.

Polling faster than 30 seconds gains you nothing: the answer is served from the same cache the page uses, so it won't be fresher, and it costs the platform nothing either.

Not to be confused with