Timeout duration must be set per operation type
Aliases: typed timeouts · timeout by action · one-size timeout
What it is
Search suggestions still missing at 3 s may time out. An annual-report export still missing at 3 s must not. Timeouts set per operation type means each user intent has its own clock for “waiting further is unreasonable”, not one site-wide 30 s. The clock faces the job’s reasonable duration, not the gateway default.
A timeout is not a performance metric. It is the legal moment to stop waiting. Set it wrong and you either kill a long job that would have succeeded, or spin a short request that is already dead.
Why it happens
People carry different duration models for different acts. Read a message, tap a like — the model is instant. Generate a video, run a reconciliation — the model is minutes. A timeout shorter than the model feels like the system lost patience; one far longer than the model feels like death without a statement. Gateways, load balancers and browsers each have defaults, those defaults protect connection pools, not the user’s model. When two clocks overlap, the user sees whichever rings first — often the crudest global default.
Operation type also splits by cost of being wrong. Idempotent reads can be short; writes, payments and deliveries cut by a timeout may already have committed on the server while the client treats them as never sent. Those timeouts must be longer, and tied to retry policy, not a single number change.
Where it stops holding
One entry that is sometimes a read and sometimes a write (“Save” sometimes local, sometimes going through review) cannot share a clock; pick by the path actually taken. When the user knows they launched a batch job, timeout can move to session scale, or yield to cancel-only. On extreme weak networks any short timeout false-kills; the clock has to rise with network quality rather than follow type blindly. Client and server timeouts must assign who handles the aftermath when one is shorter, or each side will believe the other is still working.
Applying it
- Tabulate intents: open detail, search, submit form, export, pay, upload — each with a timeout and a user-visible result of firing it.
- Do not reuse a 30 s gateway as the product timeout. The gateway clock may be longer; the product clock is shorter or longer by intent.
- Writes time out later than reads, and timeout copy must not say “not submitted” — it may have been.
- How to check: drag three classes (instant read, form write, long export) past their own clocks. The short read should leave the wait first; the export must not die at 3 s; after a payment timeout the UI must not assert “nothing was charged”.