Not open yet — signups haven't started. Join the list for the day they do.
Home/Status

Status

Is it up?

Live status lives on a monitor we don't run. A status page that goes down with the thing it's reporting on tells you nothing right when you need it most — so this one doesn't share our infrastructure at all.

99%uptime target, tracked live
~7 hrspossible shortfall a month, worst case
4components watched independently

Why it's not here

Hosted away from what it reports on

If our own infrastructure went down, a status page running on that same infrastructure would go down with it, silently, at the exact moment it mattered most. So live status runs on a separate, independent monitor, entirely outside our own systems — it stays reachable even if everything we operate is having a bad day. That's a deliberate trade-off, not an oversight: a status page's only job is to be honest when things go wrong, and it can't do that from inside the thing that broke.

What's tracked

Four components, watched independently

Each one is checked on its own, so a problem in one doesn't quietly hide inside a single "all systems normal" badge.

Hosting

Static file serving for every live site — whether a page actually loads when someone requests it.

Operational

Deploys

The queue behind Git, zip, CLI and MCP publishing — whether a deploy you kick off actually goes live.

Operational

Custom domains

DNS resolution and certificate issuance for any domain you point at us, apex or www.

Operational

Dashboard

Sign-in and account management — separate from hosting, since one going down shouldn't take the other with it.

Operational

Incidents vs. maintenance

What counts as which

An incident is unplanned — something broke, and the status page reflects that the moment it's detected, not after someone notices and decides to say something. Scheduled work is announced ahead of time, on the status page, with a window instead of a surprise; it doesn't count against the uptime figure the same way an incident does, because you knew it was coming.

In practice: a deploy pipeline error that stops sites from publishing is an incident. A planned maintenance window for the edge cache, posted a day ahead with a start and end time, is scheduled work — both show up on the status page, but only one counts against the target.

Live monitor

Check it yourself

The monitor below is the source of truth — this page is just a map to it and the numbers here are never more current than what it shows. If the two ever disagree, believe the monitor.

Open the status page

Questions

What "99%" actually means

What does a 99% uptime target mean?

It's a target, not a guarantee — the shortfall works out to roughly seven hours across a 30-day month, in aggregate. It's the number we build and monitor against, tracked live on the status page rather than asserted here.

Why not promise 99.9% or higher?

Because we'd rather state a number we can actually stand behind than one that sounds better and quietly gets missed. A promise nobody can keep isn't more reassuring than an honest one — it's just a worse surprise later.

How are incidents communicated?

On the status page itself, as they happen — what's affected, when it started, and an update once it's resolved. We don't route incident updates through email or social media first.

Is this page ever more current than the status page?

No. This page explains what's monitored and why it lives elsewhere. The status page is always the current source — if this page and the monitor ever disagree, the monitor is right.

Get on the list

See what's included on pricing or read what shipped on the changelog.

Join the list