Van Kemenade argues that humans intuitively read '98%' as 'basically perfect,' but the number compounds mercilessly across a user's daily actions. His arithmetic shows that 0.98^50 ≈ 36%, meaning roughly two-thirds of users will hit at least one failure per day even when each individual action is 98% reliable.
By submitting the essay to Hacker News where it hit 321 points, speckx amplified the position that reliability numbers must be reasoned about at the product level, not the component level. The submission's traction reflects widespread SRE agreement that per-request percentages hide user-facing pain.
The editorial argues that 2026's product surface has regressed from 'one nine of retries around a database' to 'a dozen probabilistic hops each advertising two nines' because of LLM-backed features, agent chains, and third-party API dependencies. This means the compounding tax is materially bigger than when the SRE Book was written, and marketing decks haven't caught up to the new arithmetic.
The commenter argues that vendor claims like 'S3 is designed for 99.99% availability' are honest at the component level but deeply misleading at the product level. Real user-facing availability is the product of every hop — S3 plus API gateway plus auth plus database plus LLM plus client WiFi — so a single-component number tells you almost nothing about what the user actually experiences.
Hugo van Kemenade's short essay "98% Isn't Much" hit the Hacker News front page with 321 points and a comment thread full of SREs nodding grimly. The argument is compact: humans read "98%" as "basically perfect," but in software the number is almost always compounded — across requests, across dependencies, across days — and compounding is unforgiving.
The post walks through the arithmetic most engineers know but rarely internalize. If a single action succeeds 98% of the time and a user performs 50 actions a day, the probability that every one of them works is 0.98⁵⁰ ≈ 36%. Put differently: on an average day, about two-thirds of your users will hit at least one failure. Scale that to a week and the "98% reliable" service is broken for essentially everyone.
The same math eats service meshes alive. A request that fans out through ten internal services, each independently 98% reliable, ends up at 0.98¹⁰ ≈ 81.7% end-to-end. The individual dashboards all look green. The user-facing SLO is on fire.
The piece is not new math — it's Google SRE Book chapter one dressed up for a blog audience — but the reason it's resonating in 2026 is that the industry has quietly regressed on this. LLM-backed features, agent chains, and third-party API dependencies have pushed the average product surface from "one nine of retries around a database" to "a dozen probabilistic hops each advertising two nines." The compounding tax is bigger than it used to be, and marketing decks haven't caught up.
Compare the framings. Cloud vendors sell per-component availability: "S3 is designed for 99.99% availability." That's honest at the component level and deeply misleading at the product level, because your product is not S3 — it's S3 plus your API gateway plus your auth service plus your database plus whatever LLM you're calling plus the client's flaky WiFi. A senior commenter on the thread put it well: *"Availability is not a property of a service. It's a property of a user journey."*
The SRE community has a name for the correct framing — error budgets expressed in user-visible failures — but very few teams actually track it that way. Datadog and Honeycomb both support SLOs on user journeys, but the default dashboards ship in per-endpoint percentages, and that's what leadership ends up staring at. The result is the pattern everyone has lived through: every service owner claims their SLO is green, yet support tickets keep arriving.
There's also a psychological trap: 98% feels like an A+, so nobody prioritizes the work to reach 99.9%. But the jump from 98% to 99.9% is a 20× reduction in user-visible failure rate. That is not a polish task. That is the difference between a product that feels sturdy and one that feels haunted.
The comment thread surfaced the other half of the argument too — the part Hugo hints at but doesn't fully develop. Perceived reliability isn't just about the failure rate; it's about failure mode. A 98% service where the 2% is a fast, retryable error with a clear message is a different product than a 98% service where the 2% is a 30-second hang followed by a stack trace. Users forgive quick, honest failures. They do not forgive silence.
A few concrete moves fall out of taking this seriously.
Stop reporting per-endpoint uptime to anyone who makes prioritization decisions. Report failures per user per week on the top three user journeys. If your product is a search box, that number is "how often does search fail for a user this week." Every executive dashboard should have that number and nothing else near it.
Assume every external hop is 99% at best and design for it. That means idempotency keys on every write, aggressive retries with jitter on every read, and circuit breakers that fail closed to a degraded-but-working state rather than an error page. The LLM call is the obvious offender here — model providers routinely publish 99.5% availability targets and hit them, which is still a user-visible failure every couple of hundred requests. If your agent loop makes ten calls, you're at 95%. Bake in caching, fallback prompts, and cheap-model fallbacks now, not after the first outage.
Budget the compounding explicitly. If your product SLO is 99.5% end-to-end and you have a chain of six services, each service's individual budget is roughly 99.92%, not 99.5%. Most teams size their SLOs without this arithmetic and then wonder why the composed system misses its target every quarter. A shared spreadsheet — genuinely, a spreadsheet — that lists each hop and its budget will do more for reliability than another observability tool.
Invest in the failure UX, not just the failure rate. Retry-with-exponential-backoff on the client, optimistic UI, background reconciliation, and "we saved your draft" affordances turn a 98% backend into a 99.9% perceived experience. This is the cheapest reliability lever most teams never pull.
The piece is a useful re-education for a moment when the industry is stacking more probabilistic components on top of each other than ever — LLMs, vector stores, third-party agent APIs, MCP servers, tool-use loops that call five services per turn. The teams that will ship agent products that feel reliable in 2027 are the ones internalizing today that 98% per hop is a failing grade at the product level. The math is not new. The stack is. Price the compounding in now, or explain it to your users later.
After Christmas this year, I removed the tree from our living room, and in the process of being moved, it shed of needles everywhere. I swept them up, but I missed a few areas on my first pass. So I did a second pass, but when I looked again, I saw there were still a handful left. It struck me how r
While I agree with the general sentiment, the problem here isn't developers not being familiar with statistics, it's the simple fact all of this is profit driven most of the time.I tried to purchase tickets for an event last week. I had to go through Ticketmaster as it was the only officia
The broader point is that percentages can be misleading, and are often because of that. It makes things sound better. But usually, the more accurate thing to do is use odds-notation ("1 in 50" instead of 98%). Percentages have a kind of singularity at the edges, where small numerical chang
Reminds me of the Meat Loaf song “Two Out of Three Ain’t Bad” which was released in Japan as 66%の誘惑 “66% is Good Enough” etc https://www.discogs.com/release/8303076
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
Alternatively, 98% is plenty.If your business plan requires you to capitalize on more than 98% of the market, it's already a failure. It'll never happen.As always, it's an "it depends" situation. If your userbase is largely luddites, then maybe you need to support 10+ year o