Uptime Isn't a Number: How We Think About Reliability

Every host advertises an uptime number, and almost all of them are some flavor of 99.9%. The figure is easy to print and hard to verify, because it’s usually self-reported, measured generously, and quietly excludes “scheduled maintenance.” What actually determines whether your site is up when it matters is a different conversation.

What the number leaves out

Three things, usually. It’s reported by the host, not an independent monitor. It excludes maintenance windows, which is where a lot of real unavailability lives. And it’s measured from a point of the host’s choosing, which may not reflect what your visitors experience.

Failure isn't random

Most downtime isn’t a data-center outage. It’s a bad deploy that shipped a broken build, an SSL certificate that expired, a disk that filled up, or a compromised neighbor on a shared box. These are self-inflicted or preventable failures — which means reliability is mostly about designing them out, not about the data center’s advertised nines.

How we design against it

A few deliberate choices. Deploys switch traffic only after a build succeeds, so a broken build never reaches visitors. SSL renews automatically, ahead of expiry. Each site is isolated, so a neighbor’s spike or breach can’t take yours down. And backups are restore-tested daily, so when recovery is needed it’s fast and known to work.

When something does break

No design eliminates incidents. What matters then is honesty and speed: you can reach the same support team on any plan, by email, with same-day responses on business days. No status-badge theater, no tiered escape hatch that depends on your plan.

The bottom line

Uptime is an outcome, not a promise you can put on a pricing page. The useful question isn’t “how many nines” — it’s “what happens the day something goes wrong.” You can read how the platform handles those days across /help.