What is Uptime?

#How uptime is measured

Uptime is typically expressed as a percentage of a window, or as a continuous duration since the last restart. The measurement depends entirely on what counts as up, and that definition is where the metric gains or loses its meaning.

A process that is running, a port that accepts connections, and a service returning correct responses within acceptable latency are three very different bars. Simple uptime monitoring usually checks the first or second, and users care about the third.

#Why uptime is used

Its persistence comes from being immediately understandable to anyone.

• Universal legibility: non technical stakeholders understand it without explanation.
• Trivial to measure: a basic health check produces it.
• Historical continuity: long-term trends are easy to maintain and compare.
• Marketing use: a single number for status pages and sales material.

#Limits of uptime

Uptime tracks the system rather than the experience. A service can report 100% uptime while returning errors to a third of requests, because the process was running the whole time.

It also ignores degradation entirely. Response times ten times normal produce perfect uptime and a service most users would describe as broken. And a single availability figure hides distribution: continuous partial failure and one long outage look identical.

#Uptime vs availability

The terms are used interchangeably and should not be. Uptime typically measures whether the system was running, from the system's point of view. Availability, measured properly as successful requests over total requests, measures whether users got what they asked for.

The gap between them is exactly where user affecting problems hide. A service with 99.99% uptime and 99.5% request success has a real reliability problem that the uptime figure conceals. When a number is quoted, the useful question is always which one it is and where it was measured.

#Key takeaways

• Uptime measures whether the system was running, which is a weaker claim than whether users were served.
• The definition of up, from process running to correct response within latency budget, determines the metric's value.
• It ignores degradation, so a service ten times slower than normal still reports perfect uptime.
• The gap between uptime and request based availability is where user affecting problems hide.

#Frequently asked

Is uptime a useful metric?

As a coarse signal, yes. As the primary reliability measure, no. Request based availability with a latency threshold reflects user experience far better.

Why do status pages show uptime?

It is simple, universally understood, and generally flattering. It is a communication tool more than an engineering one.

What should replace uptime internally?

SLIs measured close to the user, with SLOs and error budgets built on them.