Downtime is any period when a system is unavailable or not working as it should for its users. For a website or app, it is the time when people cannot reach it or cannot do what they came to do. Downtime is the thing uptime monitoring exists to catch, and reducing it is the point of most reliability work.
Definition: What Is Downtime?#
Downtime is the duration a service is unavailable or not performing its function. It is the opposite of uptime, the time a system is up and working. Downtime is usually measured as a percentage of total time or as minutes and hours over a period.
The word covers more than a hard crash. A site that loads but cannot process payments is effectively down for anyone trying to buy, even though the homepage works.
Planned vs Unplanned Downtime#
- Planned downtime is scheduled and expected: a maintenance window, a database migration, or a deploy that needs the service offline. It is communicated in advance and timed for low traffic.
- Unplanned downtime is the failure kind: a crash, an outage, or a broken release. This is what reliability work targets, because it is unexpected and hits users without warning.
Most uptime targets and SLAs (service level agreements) focus on unplanned downtime.
What Causes Downtime#
Common sources, roughly in order of how often they bite:
- Bad deploys: A release introduces a bug or breaks a dependency
- Software bugs: Memory leaks, unhandled errors, bad configuration
- Traffic spikes: Load beyond what the system was provisioned for
- Infrastructure failure: A server, disk, or data center goes down
- Network issues: DNS, routing, or connectivity problems
- Third-party dependencies: An external API or service you rely on fails
- Human error: A wrong command, a deleted resource, an expired certificate
How Downtime Is Measured#
Availability is usually expressed in "nines". Each nine cuts the allowed downtime by about ten times:
| Availability | Downtime per year | Downtime per month |
|---|---|---|
| 99% (two nines) | about 3.65 days | about 7.3 hours |
| 99.9% (three nines) | about 8.8 hours | about 43 minutes |
| 99.99% (four nines) | about 53 minutes | about 4.3 minutes |
| 99.999% (five nines) | about 5.3 minutes | about 26 seconds |
This is why "99.9% uptime" sounds great but still allows almost nine hours of outage a year.
The Cost of Downtime#
Downtime is expensive in more than one way:
- Lost revenue: Every minute a checkout is down is money not made
- SLA penalties: Contracts often refund customers when availability targets are missed
- Reputation: Repeated outages erode user trust and show up in reviews
- Productivity: Internal outages stop your own team from working
Downtime Is Not Always All or Nothing#
A system can be partially down: slow responses, one failing region, or a single broken feature. This "brown-out" state is easy to miss because basic checks still pass. Good monitoring watches real user paths, not just whether the homepage returns a 200, so degraded states get caught too.
How to Reduce Downtime#
- Monitor from the user's perspective. Check real journeys and multiple regions, not just a single ping. See uptime monitoring.
- Alert fast and clearly. The sooner the right person knows, the shorter the outage. Capture it in an incident report.
- Deploy safely. Use staged rollouts so a bad release does not take everything down at once. See deployment strategies.
- Build in redundancy. Remove single points of failure for the parts that must stay up.
Conclusion#
Downtime is the time a service is unavailable or not doing its job, planned or unplanned, total or partial. It is measured in nines, it costs revenue and trust, and most of it traces back to deploys, bugs, load, or dependencies. The way to shrink it is to catch it early and recover fast.
Catching downtime early is the whole job of monitoring. ObserveOne runs uptime checks from multiple regions and opens an incident the moment one fails, so a brown-out or outage is on your radar before your customers tell you.