The timeout you copied from a tutorial
Every HTTP client example on the internet sets a 30-second timeout because it has to set something. Nobody tells you that 30 seconds is also how long your request queue takes to back up into an outage.
Hammad Iqbal
Software Engineer
The timeout wasn't wrong, exactly — it was just never chosen. It arrived with the HTTP client library's example code, got pasted into a service during a sprint where nobody had time to think about it, and sat there for a year doing nothing, because most requests finish in under a second and a 30-second ceiling never gets hit on a good day. It only mattered on the one day a downstream dependency got slow instead of failing outright, and thirty seconds turned out to be more than enough time for every connection in the pool to fill up waiting.
- A default timeout copied from documentation is tuned for the example, not for your traffic or your dependency's failure modes.
- A slow dependency that never times out is worse than one that fails fast — it holds connections and threads instead of freeing them.
- The right timeout is set from what a good response actually takes, with headroom, not from whatever number shipped with the library.
Slow is more dangerous than down
When a dependency returns an error immediately, the caller fails fast, frees its connection, and moves on — unpleasant, but contained. When a dependency goes slow instead of down, every caller holds a connection, a thread, or a worker slot open until its timeout fires. If that timeout is 30 seconds and your service normally responds in 200ms, one slow dependency can tie up every worker your process has, and the outage looks like your service failed even though the actual fault is three hops downstream.
The tutorial's timeout was never about you
Example code needs a timeout that won't flake during a demo, so it picks something generous and moves on — 30 seconds is common precisely because it's long enough that nobody watching a tutorial ever sees it fire. That number encodes nothing about your p99 latency, your connection pool size, or how many concurrent requests you can afford to have stuck waiting at once.
- A connection pool of 20 with a 30-second timeout can be fully exhausted by one slow dependency in under a second of sustained load
- A timeout longer than your own service's SLA guarantees you'll breach that SLA before you even get to return an error
- Different calls need different timeouts — a cache lookup and a report-generation call aren't the same kind of wait
Set it from your own numbers
A sane timeout comes from your dependency's normal response time plus enough headroom to absorb real variance — not from a round number that felt safe. Pair it with a smaller connection pool and a circuit breaker so a slow dependency fails fast and gets isolated instead of quietly draining every resource your service has, one hung request at a time.
If you can't say why your timeout is the number it is, it's not configured — it's inherited, and it'll fail exactly when a slow dependency needs you to have thought about it.
Have a project this kind of thinking applies to?
Tell me what you're building — I read every message myself.