How we think about uptime, and what we tell clients to ignore
Every enterprise infrastructure evaluation eventually gets to the uptime number. Someone on the client side has pulled the SLA document, found the figure, and put it in a slide. The number is usually 99.9% or 99.99%, and it's usually presented as if higher is unambiguously better.
It's more complicated than that. Some of what's in those numbers is meaningful. Some of it isn't. Here's how we read them.
What the number doesn't tell you
An uptime SLA is a commitment about availability during the measurement window, usually a calendar month. What it doesn't specify: what counts as downtime. Planned maintenance windows are often excluded. Partial degradation — where the system is technically up but performing below usable thresholds — may or may not qualify. And the remedy for an SLA breach is almost always a service credit, which compensates for the contract value of the downtime, not the business cost of it.
That last point is worth sitting with. A 99.9% SLA allows for roughly 8.7 hours of downtime per year. If your business processes $2M a day through a system that's down for 8 hours, the service credit you receive under most SLAs will not reflect that number.
The difference between availability and reliability
Availability is whether the system is running. Reliability is whether it's running correctly, under load, in the conditions you actually operate in. A system can be available — responding to requests — while being unreliable: returning errors, degrading under traffic, or behaving differently in production than it did in the test environment.
When we're evaluating infrastructure for a client, we ask about both. The availability number is in the contract. The reliability question requires a different kind of interrogation: What does the system do under 2x normal load? What's the behavior when a downstream dependency is slow, not down? Has anyone actually run a failover drill, or is the failover architecture theoretical?
Google Cloud, for example, publishes target availability of 99.999% for multi-region deployments — with an estimated maximum monthly downtime of around 52 seconds. That's a meaningful engineering commitment. But it's a commitment about availability, not about what your application does when traffic spikes or when a dependent service misbehaves.
What we actually watch
The metrics that matter to us in practice: error rate, not just uptime. Latency at the 95th and 99th percentile, not just the average. Time to detect an incident, and time to restore service — separately, because detection latency is often where systems fail before anyone notices.
We watch those numbers continuously, not monthly. An availability SLA is a lagging indicator. By the time it's breached, the problem has already happened. What we want are the signals that tell us something is wrong before the threshold is crossed.
What to ignore
The specific number in the SLA, in isolation, is the thing to pay the least attention to. 99.99% from a vendor who excludes maintenance windows and measures at the infrastructure layer rather than the application layer may represent a weaker commitment than 99.9% from a vendor who measures end-to-end, includes all incident types, and has a track record you can verify.
Read the definitions section of the SLA document. That's where the number gets its meaning, and that's where you'll find out what you're actually being promised.
The uptime figure is the start of the conversation. It's not the answer.