Your users have been working around the same broken widget for four months. They refresh it twice, open a second tab, copy the number out by hand, and tell the new hire, “yeah, that part never works right.”
Nobody got paged.
The API was up. The queues were moving. Error rates looked normal. Every system engineering had decided to be afraid of was reporting green. That’s how you end up with a trash fire in the lobby while every smoke detector in the building is wired to the server room.
Sleep-protection architecture
In every shop I’ve worked in, the same thing is true: developers quietly decide how much failure users will put up with, and nobody else is ever asked.
I have an admin page in production right now that only works on the second load. The first render kicks off a job I hung on page load, because I had a few hours to ship it and never went back. It gets used twice a year. Everyone who touches it knows to refresh. That’s not a bug. It’s a decision I made about someone else’s time and never wrote down anywhere they could see it.
Here’s how it happens more generally. The last thing any developer wants is to be woken up at 3am. So the alerts get pointed at the things the developer is worried about, and they’re usually worried about weaknesses they already know are there. The pager maps the developer’s anxieties, not the user’s workflow.
Companies watch the failures they already understand. The expensive ones happen outside that model.
A landing page and a widget are not the same millisecond
“If your site isn’t instant, you lose customers.” Those studies are real. Look at what they measured: sales pages. Search results, product listings, checkout. Then the finding gets carried, unchanged, into places nobody measured.
A visitor loads your marketing page once, on a phone, on bad Wi-Fi, in a busy browser. A modest delay gets blamed on the environment. Nobody decides your company is incompetent because a page took 1.4 seconds instead of 1.1.
Inside the product, the blame flips. A paying user opens the same widget two hundred times a day. They know what normal feels like. They notice the hesitation. A small delay, repeated across work they have to do, is friction on their job, and they know exactly whose fault it is. Both are measured in milliseconds. They are not the same thing to fix.
Failure enters at the boundaries
Your code can be tested constantly, at scales normal use will never reach. You control the inputs. You can inspect the state. You can compare the output to what you expected.
You can test an interface. You can watch someone use it and interview them after. But you cannot test the user. You can’t inspect the state that produced their behavior. You can’t know they understood the task, brought their real context, acted naturally while being watched, or can honestly explain why they did what they did. Their explanation isn’t the internal state. It’s one more output from the black box.
And that black box arrives carrying a mental model built from documentation, old habits, office folklore, other software, onboarding, and promises made elsewhere in your business. A sales process built to beat objections rather than diagnose fit will inject expectations no product team ever agreed to support. The promise made on that call is third-party data feeding your user’s mental model, and it’s exactly as reliable as any third-party API.
When a user keeps trying, that’s the signal
When someone repeatedly tries to make your system do something else, one of two things is probably true.
Missing capability
They’re reaching for something the product should do. That’s demand showing up before it has a feature request attached.
Wrong problem (more common)
They’ve attached your product to a need it was never meant to serve, usually because sales, docs or prior software told them it would.
Either way, somebody should step in. The job of customer success isn’t to teach people which buttons to press until the ticket goes away. It’s to back up far enough to understand the problem the customer thinks they’re solving. Then make an honest call: build the missing thing, show them the workflow that already exists, or help them go use the product they actually need.
Nobody likes the third answer. Sometimes it’s right, and occasionally it’s the best outcome for you. A customer badly matched to your product isn’t a retention win. Keeping them means preserving their frustration, eating your support capacity, and eventually getting blamed for a result you were never built to produce. I’ve told plenty of prospects “you don’t need my thing, you need theirs.” I’d rather lose the deal than spend two years being blamed. A yes only means something when a no was genuinely available.
What this looks like in practice
On the timing platform I build, a broken pipeline produces two different experiences on purpose. Race officials get alerted immediately and loudly, because they can act: hold the call, fall back to manual, tell the tower. Spectators see the leaderboard slow down, with a message that the data is stuck in the pipes, not lost. Same fault, two audiences, two designs.
The naive version is one generic error for everyone. The common version is worse: a spinner that keeps spinning and tells the user nothing, which is a product quietly lying to the person who trusted it.
That decision was made at design time, before anyone had used the system. It couldn’t have been added cheaply later: adding it means threading a new state through every layer that touches the stream. It’s a seam, not a feature, and seams are nearly free before you build and nearly impossible after. That weekend has its own story →
Code is the part you can measure over and over. Test it brutally, so routine engineering failure costs as little human attention as possible. Then spend that attention on the part you can’t model: the person carrying a mental model you didn’t write, doing things you didn’t foresee.
Things will break at the boundaries. When they do, route the alarm correctly. Fail loud at the operator, who can act. Fail soft at the audience, who can’t. Users were never the right people to find out first. For most of the internet’s history, they were just the only monitoring anyone actually deployed.