Downtime is the time a website cannot do its job. Visitors may see an error page, a page that never finishes loading, or a browser warning. What matters is the result: they cannot use the site.
Downtime is the counterpart of uptime. A site with 99.9% uptime in a 30-day month has about 43 minutes of downtime.
Planned and unplanned downtime
Planned downtime is chosen in advance. Typical reasons are a database migration, a server upgrade, or a major release that cannot run alongside the old version. Good practice is to schedule it for quiet hours, tell users beforehand, and show a clear maintenance page. A server that is deliberately switched off for maintenance often answers with 503 Service Unavailable, which signals a temporary condition and can include a Retry-After header telling clients when to come back.
Unplanned downtime is everything else: failures nobody scheduled. It is the kind that hurts, because it arrives without warning and the clock runs until someone notices and fixes it.
Contracts and reports often treat the two differently. Many service level agreements exclude announced maintenance from the calculation. Whether that applies to a given site depends entirely on the wording that was agreed.
Common causes
| Cause | What happens | What a visitor often sees |
|---|---|---|
| Server failure | The machine or virtual server crashes, runs out of memory or disk, or is overloaded | Connection refused, timeout, or a 5xx error |
| Network problem | A link, firewall rule, or provider fault stops traffic between the visitor and the server | Timeout, "site can't be reached" |
| DNS problem | The domain name does not resolve, because a record is wrong, deleted, or the domain expired | "Server not found" |
| Certificate problem | The TLS certificate expired or does not match the domain | A full-page browser security warning |
| Application failure | A bug, a failed deployment, or a broken dependency crashes the application | A 500 error, or a blank page |
| Overload | A traffic spike or a heavy job uses all available capacity | Very slow pages, 503 or 504 errors |
| Third-party dependency | A payment, login, or database service the site relies on stops responding | A working page where one function fails |
Many outages combine causes. An overloaded server fails, and the restart is delayed by an expired certificate on the backup. Looking at the first failure usually matters more than the last symptom.
How downtime shows up in HTTP
When a visitor loads a page, the server returns an HTTP status code. Codes in the 5xx range, such as 500, 502, 503, and 504, report that the server failed. If the server cannot be reached at all, there is no status code, only a timeout or a connection error. The meaning of each class is covered in HTTP status codes.
What a web request check cannot see
This is the most important limit to understand. A monitoring check that requests a page and reads the answer can only report what the server says. It cannot tell whether the site works.
A server can return 200 OK while:
- the shopping cart fails when someone clicks "add",
- the login form rejects every password,
- the page loads but is empty because a backend call failed,
- an error message is printed inside an otherwise normal page.
From the monitor's point of view the site is up. From a customer's point of view it is down. Detecting such failures needs checks that follow real user paths, or application-level alerts, or both. A simple address check is a reliable first line of defence for outages where the server does not answer or answers with an error, and nothing more than that.
Consequences
The effects of downtime depend on what the site is for:
- Lost revenue when customers cannot order or pay.
- Lost trust when users meet an error where they expected a service.
- Support load as people ask whether the problem is on their side.
- Contract penalties when an agreement defines availability targets and credits.
Detecting and recovering
Downtime is shortened by three things: noticing quickly, understanding the cause, and having a way back.
- Detect. A monitor checks the site at an interval and raises an alert after repeated failures, so a single dropped request does not wake anyone. UptimeWire, for example, repeats a failed check twice, about 20 seconds apart, before it opens an incident.
- Diagnose. The failed check records a reason, such as a timeout, a connection error, or a status code. That narrows the search: a DNS error and a 500 error point to completely different places.
- Recover. Common recoveries are restarting a service, rolling back a release, restoring a certificate, or fixing a DNS record. Once the site answers correctly again, checks pass and the incident closes.
- Learn. A short note on the cause and the fix, kept with the incident, helps the next time.
The time from the start of the outage to the moment someone knows about it is part of downtime too. That is why the check interval matters: a site checked every minute can be noticed sooner than one checked every ten minutes.