Running & Maintaining a Site

Downtime

Definition

Downtime is measured in minutes of unavailability, and its definition matters more than its arithmetic. A provider usually counts it as failed requests to the origin, which misses several ways a site can be useless while technically up: an expired certificate that makes every browser refuse to proceed, a DNS record pointing nowhere, a deploy that published an empty directory, a page returning 200 with no content. Outages are measured against an allowance — 99.9 per cent availability permits about 43 minutes in a month, and 99.99 per cent permits about 4 — so a single bad afternoon can use a year's budget. Partial downtime counts too: if one page in ten is broken, that is not a tenth of an incident to the person who wanted that page.

Why It Matters

The cost of an outage is rarely the hosting fee. A shop that takes 60 orders a day loses roughly two and a half an hour; a conference site that is down on the morning tickets open loses the whole spike and does not get it back. There is a slower cost too: search crawlers that repeatedly find a site unreachable will reduce how often they come back, and a page removed from the index takes longer to return than the outage lasted. And most of the total is usually detection, not repair — an hour before anyone notices plus ten minutes to roll back is a 70-minute outage that could have been a 15-minute one.

How It Works

For a static site the causes are a short list, and knowing it shortens the fix. DNS: the record was edited, the domain lapsed, or the nameservers changed and the change has not propagated. Certificate: renewal failed and browsers now block the site outright. Content: a bad upload replaced the files, or the entry point is no longer named 'index.html', so the host has nothing to serve. Platform: the host itself or its CDN has a regional failure, which you confirm on their status page rather than by debugging your own files. Account: storage or bandwidth limits reached, or billing failed. Work down that list in order, because the first three account for most incidents and the first fix for all of them is to restore the last known-good version before investigating.

Real-World Example

A restaurant publishes its menu at brook-lane-menu.99helpers.site, linked from every listing and the QR codes on the tables. One Friday the custom domain stops resolving because a DNS record was tidied up during unrelated work. Requests to the 99helpers address still succeed, which narrows the cause in seconds, and the record is restored. Total unavailability is 25 minutes across the early evening service — under an hour on paper, and roughly forty covers scanned in that window that got a browser error instead of a menu.

Common Mistakes

  • Counting only complete outages — a page that loads with its stylesheet missing is down for the visitor even though every request returned 200
  • Testing from a browser that has the working page cached, concluding the site is fine, and leaving the real outage running
  • Treating a scheduled maintenance window as free downtime without checking the analytics for when people actually visit
  • Measuring only from your own country when the audience is elsewhere, which hides a regional failure entirely

Related Terms

Put a file online in seconds

Drop in a document, an image, a page or a whole static website and share the link — free, with no build step and no server to set up.

Host a file free →