Glossary
Downtime
Downtime is the time a service was unavailable to its users, the complement of uptime and the number that actually costs something.
Downtime is the time a service spent unavailable. It is the same measurement as uptime read from the other end, and it is the more useful of the two in conversation because it is stated in minutes rather than in decimal places. "We allow 43 minutes a month" lands where "we target 99.9%" does not.
Downtime comes in two kinds that are measured the same way and treated differently. Planned downtime is a maintenance window announced in advance: customers were told, the work was scheduled, and most SLAs leave it out of the calculation. Unplanned downtime is everything else, the outage nobody chose, and it is the kind an SLA counts and a status page has to explain while it is happening.
The hard part is deciding what counts. A total outage is easy. A service returning errors for one endpoint, or for one region's customers, or only for signed-in users, is downtime for the people affected and uptime for everyone else — including for a monitor pointed at the homepage. This is why what you monitor matters more than how precisely you measure it: a check against a static marketing page will report excellent availability through an outage of the product itself.
Downtime is also usually recorded from the outside in, which means it starts when a check fails and ends when a check passes. Both edges are quantised to the check interval, so a recorded outage is accurate to roughly one interval in each direction. Nobody's downtime figure is exact, and a vendor quoting seconds of annual downtime is quoting arithmetic, not observation.
| Type | What it looks like | How to catch it |
|---|---|---|
| Planned | A maintenance window announced in advance. | Scheduled maintenance on the status page, so the failures during it are expected and explained. |
| Unplanned | A crash, a bad deploy, an expired certificate, a full disk. | A check against the service itself, run every minute or so. |
| Partial | One endpoint, one feature or one group of users fails while the rest works. | A separate check for each critical path, not one check on the homepage. |
| Degraded | Everything answers, but slowly enough that people give up. | A response time threshold, as well as the up or down check. |
| Third-party | A payment, email or cloud provider the service depends on is down. | Watching the provider's own status page beside your own checks. |
Questions
What is downtime?
Downtime is the time a service was unavailable to the people using it. It is usually stated in minutes over a period: 43m 12s in a 30-day month is what a 99.9% target allows.
What is the difference between downtime and an outage?
An outage is the event: the service stopped working. Downtime is the measurement: how long it was unavailable. One outage produces some amount of downtime, and a month's downtime is the sum of every outage in it.
What is the difference between planned and unplanned downtime?
Planned downtime is maintenance announced in advance, which most SLAs exclude from the availability figure. Unplanned downtime is any outage that was not scheduled, and it is the downtime an SLA counts against its target.
How much downtime does 99.9% uptime allow?
43m 12s in a 30-day month and 8h 45m 36s in a 365-day year. 99.99% allows 4m 19s a month and 52m 34s a year. The uptime calculator runs the same arithmetic for any target.
Is slow performance downtime?
Not by most definitions: a service that answers slowly is up, and is usually called degraded. It still costs users, so it deserves a response time threshold of its own, and an SLA can define a response time above which a request counts as failed.
Uptimely checks as often as every minute on every plan, the free one included, and a failed check shows as downtime on every status page the monitor is on, whether or not it pages anyone.
Start monitoring free →Product feature
Part of the Uptimely monitoring glossary — plain definitions of the vocabulary uptime monitoring, incident response and status pages are discussed in. Something here read wrong to you? Email support@getuptimely.com.