HTTP Timeout Calculator
Calculate worst-case total time from first request to final failure.
| Attempt | Starts at | Timeout at | Retry delay | Cumulative |
|---|
Timeline
Stop building retry logic from scratch
Recuro handles retries automatically. Configure timeout and retry strategy per schedule, and we take care of the rest — execution, backoff, and alerting when attempts are exhausted.
Start scheduling for free →Understanding HTTP timeouts and retry budgets
Every HTTP request has two possible outcomes: a response arrives, or the connection times out. When you add retries on top of timeouts, the worst-case duration grows quickly. A 30-second timeout with 3 retries and exponential backoff can mean over 2 minutes from the first request to the final failure — time your users or downstream systems might be waiting.
Your retry budget is the total time you are willing to spend before giving up. It is the sum of all timeouts (time in flight) plus all retry delays (time waiting). Understanding this number is critical for setting SLAs, configuring circuit breakers, and sizing connection pools. If your retry budget exceeds your SLA, you need to reduce timeouts, retries, or both.
Exponential backoff is the standard approach because it gives failing services progressively more recovery time. Adding jitter prevents synchronized retry storms when many clients fail at the same moment. A max delay cap ensures you never wait too long between retries — without it, exponential growth can push individual delays into minutes or hours.
Recuro lets you configure timeout, retry count, backoff strategy, and delay caps per schedule from the dashboard. We execute your HTTP requests on schedule, handle retries with your chosen strategy, and alert you when a schedule exhausts its retry budget — so you can focus on building, not plumbing.
Frequently Asked Questions
How do I choose the right HTTP timeout for my requests?
Start with your server's p99 response time and add a buffer. For most APIs, 10-30 seconds covers normal responses. For webhooks, 5-10 seconds is common since you want fast feedback. Too short and you'll get false failures on slow responses; too long and you'll tie up connections waiting for hosts that will never respond. Monitor your actual response times and adjust — the goal is to catch genuine failures quickly without cutting off legitimate slow responses.
What retry strategy should I use for HTTP requests?
Exponential backoff with jitter is the industry standard for HTTP retries. Fixed delays risk synchronized retry storms, and linear backoff doesn't space retries out fast enough under heavy load. Exponential backoff (e.g., 1s, 2s, 4s, 8s) gives failing services progressively more recovery time. Adding jitter (randomness) prevents the "thundering herd" problem where all clients retry at the same moment. Cap your max delay to avoid waiting excessively between retries.
When should I implement a circuit breaker instead of retrying?
Use a circuit breaker when repeated failures indicate a systemic issue rather than a transient blip. If your retry budget is exhausted (e.g., 3-5 retries over 60+ seconds) and the endpoint is still failing, a circuit breaker stops further requests for a cooldown period. This protects both your system (from wasting resources on doomed requests) and the downstream service (from being hammered while it's struggling). The circuit breaker "half-opens" periodically to test if the service has recovered.
⌘Enter to run · ⌘⇧C to copy