A staff member stares at a frozen screen, finger hovering over refresh, caught in decision paralysis:
Is the system sluggish or down? Should I wait? What if it comes back right after I switch to paper?

The timeout threshold is the point at which someone decides to stop waiting for system recovery and switch to manual processes.

This is not a technical specification. It’s a human decision made under radical uncertainty.
It happens daily. Healthcare facilities, government offices, retail counters, anywhere frontline staff depend on systems that occasionally fail.

The staff member can see the costs of waiting: the queue lengthening, customers frustrated, colleagues looking to them for guidance. But they cannot see the one thing they need: how long until recovery. Thirty seconds? Five minutes? An hour? The system offers no signal.

Decision-making degrades under exactly these conditions. Heuristics fail.
Availability bias. If the system recovered quickly yesterday, they wait longer today. If it failed last week, they switch early today. Neither tells them anything about this freeze.
Loss aversion. The pain of choosing wrong exceeds the relief of choosing right. This pushes toward paralysis where they neither wait nor switch but hover in indecision while the queue compounds.
Authority gradients. Junior staff wait for senior staff to call it, even when seniority adds no information. The decision escalates not because escalation helps, but because it distributes blame.
Confirmation bias. Once committed to a path, ambiguous signals get reinterpreted to support it. Decided to wait? That slightly faster loading animation means recovery. Decided to switch? Same animation means nothing.

No team owns this space. Interface designers focus on the system working. IT focuses on the system broken. Operations focuses on normal workflow. The ambiguous middle belongs to no one.
The question “how long should staff wait?” implies a correct answer.