June 20, 2026
Fast on paper, rage in real life
Alice. Alice Is Impatient
Your app says “fast,” your users say “absolutely not,” and the comments are fighting
TLDR: The post argues that a service can look speedy by the numbers while still feeling slow to users, because people remember the long waits most. Commenters turned that into a mini brawl over bad metrics, missing math, and whether companies should track unhappy users instead of bragging about averages.
A deceptively simple blog post just lit up the comment section with a very relatable accusation: your service might look fast on paper while feeling painfully slow to actual humans. The post’s big point is that users don’t experience an average the way engineers measure it. If a site usually responds quickly but occasionally takes forever, those bad moments loom large. Same for outages: a company can brag that the “average time to recover” is under a minute, while users remember being stuck for what feels like an eternity. In other words, the spreadsheet says “fine,” but Alice and Alex are out here smashing refresh and losing their minds.
And wow, the commenters had thoughts. One camp basically yelled, stop worshipping the average and look at the ugly worst-case moments, with one person arguing that nearly everyone will eventually hit one of those “rare” bad requests anyway. Another camp wanted receipts, not vibes: “Show me the math!” became the thread’s mini battle cry, with readers poking at the missing explanation behind the formula. Then came the spicier rebellion: one commenter said even p99 — a way of tracking the slowest 1% — is no longer enough, and that teams should measure how many real people have an “unacceptable experience” instead. The funniest drive-by came from someone using Amazon as the example of user pain, joking that searching for an author can somehow lead you to random jigsaws. Brutal, petty, and honestly memorable.
Key Points
- •The article says service operators and users can both be correct when they report very different average latency or outage durations because they are measuring different things.
- •It attributes the gap between service metrics and user perception to the inspection paradox, where users experience a time-weighted version of the latency or recovery distribution.
- •A simulation in the article uses median and p99 values, fits a log-normal distribution, and compares service-level means with customer-experienced means.
- •In the article’s outage example, a 30-minute median recovery time and a 10-hour p99 produce an MTTR of a little over 1 hour but a customer-experienced mean recovery time of around 6 hours.
- •The article argues that tail latency and long recovery times are critical to understand and that trimmed measurements can hide right-tail behavior that strongly affects customer experience.