--- title: "Timeouts and Deadlines in Distributed Systems" url: https://daily.dev/posts/timeouts-and-deadlines-in-distributed-systems-nhzdf0eiq source_url: https://levelup.gitconnected.com/timeouts-and-deadlines-in-distributed-systems-b0cbcfa9d08b type: article source: "gitconnected" published: 2026-08-14T13:53:27.416Z updated: 2026-08-14T13:53:54.640Z tags: ["distributed-systems", "grpc"] reading_time: 17 upvotes: 0 comments: 0 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Timeouts and Deadlines in Distributed Systems **[gitconnected](https://daily.dev/sources/gc)** · 17 min read · 0 upvotes · 0 comments ## Summary A deep dive into timeouts as a resilience pattern in distributed systems: what a timeout actually bounds, how to derive a sane value from real latency percentiles, the difference between per-attempt and overall budgets, how deadlines must propagate across service hops (unlike restarting timeouts), and why a timeout never proves work didn't happen — meaning any retry behind a timeout requires idempotency. Includes a real incident from a radiology imaging platform where an unconfigured 30-second default timeout caused a broad outage, and a .NET/Polly code example composing overall, retry, and per-attempt timeout layers. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What is the difference between a per-attempt timeout and an overall timeout in a retry policy? A per-attempt timeout bounds a single call, while an overall timeout bounds the entire operation including all retries and pauses between them. They must both be set because the real worst-case latency is per-attempt timeout multiplied by the number of attempts, plus backoff delays — for example, a 2-second per-attempt timeout with 3 retries and exponential backoff of 1 and 2 seconds produces a 9-second worst case, not 2 seconds. _daily.dev surfaces practical resilience patterns like this for engineers tuning retry and timeout policies._ ### What is the difference between a timeout and a deadline when a request passes through multiple services? A timeout is a duration that restarts fresh at each hop ("two seconds from here"), while a deadline is one fixed instant the entire request chain shares ("stop at 12:00:02"). Without deadline propagation, a service three hops deep can start a multi-second query for a caller that already gave up, wasting CPU and holding connections for work nobody will read. _engineers designing multi-hop service chains can track patterns like deadline propagation through daily.dev._ ### Why is it unsafe to automatically retry an HTTP call after it times out? A timeout only tells you that no response arrived in time — it does not tell you whether the server actually completed the operation, such as charging a card or writing a database row. Retrying a timed-out call that actually succeeded means running the operation twice, so any retry behind a timeout requires the operation to be idempotent, typically via a unique request key the server uses to detect duplicates. _daily.dev helps developers building idempotent, retry-safe APIs keep up with patterns like this._ ## Similar posts on daily.dev - [The reliability cost of default timeouts](https://daily.dev/posts/the-reliability-cost-of-default-timeouts-1uhreyzlv) · InfoWorld · 1 upvotes · 0 comments - [3 Resilience Patterns That Keep a Backend Service Up When Its Dependencies Aren't](https://daily.dev/posts/3-resilience-patterns-that-keep-a-backend-service-up-when-its-dependencies-aren-t-by1axueza) · The T-Shaped Dev · 0 upvotes · 0 comments --- Tags: [#distributed-systems](https://daily.dev/tags/distributed-systems), [#grpc](https://daily.dev/tags/grpc) [View this post on daily.dev](https://daily.dev/posts/timeouts-and-deadlines-in-distributed-systems-nhzdf0eiq)