# Uptime is not reliability: the gray failures green dashboards miss (Problem Scope 1/5) > A server can pass every health check and still run below spec. Why uptime misses gray failure, and the three properties that make infrastructure reliable. - URL: https://blog.asama.ai/blog/issue-01-asama-uptime-is-not-reliability/ - Author: Manish Gautam - Published: 2025-10-01 - Tags: Fleet problems Uptime tells you a server answers its health checks. It does not tell you the server is doing its job at spec, and the failures that hurt most live in that gap: gray failures, where the system looks healthy to its own monitoring while the work it serves degrades. Somewhere in your organisation, a dashboard is showing green. Health checks passing. Services responding. Alerts quiet. By every conventional measure, the infrastructure is up. And somewhere in that same infrastructure, a server is running at 60% of its expected compute capacity because [a BIOS update two weeks ago silently changed its performance profile](https://blog.asama.ai/blog/article-01-asama-your-team-is-trapped-in-a-loop). Another node is throttling under load because a cooling anomaly nobody connected to the right dashboard has been compounding for days. A storage cluster is serving IO requests with `P99` latency that has been creeping upward for a month: not enough to trip an alert, enough to quietly erode every SLA that depends on it. The dashboard still says green. > Uptime measures availability. It says nothing about correctness, performance, or whether the infrastructure is actually doing what you think it is. ## How we got here Uptime became the dominant reliability metric because it is easy to measure. You either respond to a health check or you don't. The binary nature of it made it reportable, auditable, contractual. SLAs were written around it. Dashboards were built around it. Careers were evaluated against it. The problem is that modern infrastructure fails in ways that uptime cannot see. It fails gradually. It fails partially. It fails in ways that look like application problems, network problems, or workload problems, until someone eventually traces the root cause back to [a hardware layer that nobody was watching](https://blog.asama.ai/blog/article-02-asama-where-the-loop-always-starts) because the hardware was up. Researchers at Microsoft described this pattern in 2017 as gray failure, and named its key feature, differential observability: a system's failure detectors miss problems that its applications are already suffering ([Huang et al., HotOS 2017](https://www.microsoft.com/en-us/research/publication/gray-failure-achilles-heel-cloud-scale-systems/)). An uptime check is exactly that kind of detector. ## What reliability actually requires Real reliability has three properties that uptime does not capture. ### Performance integrity The system is not just available: it is performing at the level it is expected to perform. A server running well below spec because of a misconfigured power profile is available and unreliable at the same time. ### Predictability The system behaves consistently under load. Intermittent degradation that averages out in a daily metric is not predictable infrastructure: it is unreliable infrastructure with a flattering time window. ### Observability at the right layer You know what the infrastructure is doing not just at the application layer, where symptoms appear, but at [the hardware layer, where causes originate](https://blog.asama.ai/blog/pci-device-metrics-in-prometheus-node-exporter). A system you cannot observe where it fails is one you are managing reactively. --- None of these require a different infrastructure. They require a different set of questions, the instrumentation to answer them, and [a way to act on the answers](https://blog.asama.ai/blog/article-03-asama-what-happens-when-the-loop-ends) before the degradation compounds. ## Food for thought What percentage of your current infrastructure is available but not performing at spec? If you don't have a number, that's the gap worth closing first. **Update, October 2026.** Asama's fleet observations put about 65 servers in every 1,000 in that state: up, silently degraded, and below every alert threshold. Asama's fleet visibility is generally available, and detection built on it has been validated; investigation and remediation are expanding. To find your own number, book a live comparison against your stack at [asama.ai](https://www.asama.ai), or write to contactus@asama.ai.