AI News
13 Aug 2026
Read 9 min
How to increase third-party request timeout and stop errors
Increase third-party request timeout to prevent 500 errors and keep external content loading reliably.
To stop timeout errors from outside APIs, increase third-party request timeout the right way. Measure real latency, raise deadlines across your client and proxies, pass supported timeout parameters, add retry with backoff, and monitor results. Also cut wait times with caching and async jobs so requests finish before any deadline hits.
A 500 error that says a third-party request timed out often means your app gave up before the outside service replied. Some services let you extend the wait with a timeout query parameter, like ?timeout=50000&url=…, but you must align this with your client, server, and proxy settings. The steps below show how to prevent timeouts without causing new problems.
What a timeout really means
Where timeouts can occur
- Your HTTP client: browser fetch, mobile SDK, Axios, Requests, OkHttp, HttpClient
- Your server or middleware: Node, Python, Java, .NET
- Your proxy or CDN: NGINX, HAProxy, Cloudflare, AWS ALB/ELB
- Your platform: serverless function limits, router idle timeouts
- The provider: their own deadline or job runtime cap
How to increase third-party request timeout safely
1) Measure before you change
- Log start and end time for each provider call.
- Find P50, P95, and max latency during busy hours.
- Check the provider’s documented limits and SLA.
2) Choose a sensible new deadline
- Pick a timeout near the P95 latency plus a small buffer (10–30%).
- Do not set it to infinity. Long waits tie up threads and sockets.
- Have different timeouts per endpoint if they behave differently.
3) Update every layer
- Client library timeout (the code that makes the call)
- Reverse proxy and load balancer idle/read timeouts
- Server framework timeouts and request limits
- Background job runners if they proxy the request
4) Pass provider-supported timeout parameters
Some APIs let you request more time. If docs show a parameter like timeout in milliseconds, use it. For example: ?timeout=50000&url=… when you increase third-party request timeout. Only pass values the provider allows, and keep them within your own deadline.5) Add safe retries with backoff
- Retry only idempotent methods (GET, HEAD, safe POST with idempotency keys).
- Use exponential backoff with jitter (e.g., 200ms, 400ms, 800–1200ms).
- Set a total deadline so retries do not exceed your timeout.
6) Propagate a single deadline
- Compute a deadline at the start of the request.
- Pass it downstream (header like x-request-deadline or a context object).
- Cancel work when the deadline is near to free resources.
7) Monitor after you change
- Watch success rate, median and P95 latency, and concurrency.
- Alert on rising queue length and thread/socket usage.
- Roll back if you see saturation or cascading timeouts.
Quick configuration examples
Frontend and mobile
- Axios (JS): axios.get(url, { timeout: 50000 })
- Fetch (JS): use AbortController with setTimeout to abort after 50s
- Android OkHttp: setCallTimeout/readTimeout/connectTimeout to 50s
- iOS URLSession: configure timeoutIntervalForRequest = 50
Backend clients
- Node Axios: axios.create({ timeout: 50000 })
- Node fetch: AbortController + setTimeout for 50,000 ms
- Python Requests: requests.get(url, timeout=(5, 50)) # connect, read
- Go http.Client: Timeout: 50 * time.Second
- Java OkHttp: client.readTimeout(50, SECONDS)
- .NET HttpClient: httpClient.Timeout = TimeSpan.FromSeconds(50)
- cURL: –max-time 50
Proxies and platforms
- NGINX: proxy_connect_timeout 10s; proxy_read_timeout 50s; send_timeout 50s;
- HAProxy: timeout connect 10s; timeout server 50s; timeout client 50s;
- AWS ALB: Idle timeout (set to 60s+ if calls may run that long)
- Cloudflare: hard cap around 100 seconds for HTTP; cannot exceed
- Serverless (examples): Vercel/Netlify/Cloud Functions have max execution times; design around these
- Heroku Router: 30s limit on non-streaming responses; use Streaming, WebSockets, or background jobs if you need longer
Reduce the need to wait longer
Make the work smaller
- Use caching for repeat data. Set a short TTL if data changes often.
- Paginate or request only needed fields instead of full payloads.
- Compress responses (Gzip/Brotli) if payloads are large.
Change the pattern
- Use webhooks or polling for long tasks. Return 202 Accepted with a job ID.
- Queue heavy jobs and let the user check status later.
- Stream partial results to keep connections active and avoid idle timeouts.
Lower network overhead
- Enable keep-alive and HTTP/2 to reuse connections.
- Warm DNS and TLS sessions. Reuse connection pools.
- Place services closer together or use a faster region when possible.
Testing and monitoring
Before rollout
- Replay real traffic in a staging environment.
- Load test slow endpoints with deadlines enabled.
- Chaos test by injecting latency and observing retries and timeouts.
After rollout
- Track error codes by cause: client-timeout, proxy-timeout, provider-timeout.
- Log timeout_ms requested vs. actual duration per call.
- Set alerts for rising P95/P99 and saturation signals.
(Source: https://seekingalpha.com/news/4629684-north-korean-hackers-build-ai-tools-for-cyberattacks-report)
For more news: Click Here
FAQ
Q: What does a 500 error saying a third-party request timed out mean?
A: A 500 error that says a third-party request timed out usually means your app gave up before the external service replied and some layer in the request path hit its deadline. To resolve it you should measure latency and, where appropriate, increase third-party request timeout and align client, proxy, and server settings across the stack.
Q: How should I choose a sensible timeout value for provider calls?
A: Log start and end times to find P50, P95, and peak latency and pick a timeout near the P95 plus a small buffer (10–30%). Do not set infinite timeouts; instead increase third-party request timeout per endpoint as needed to avoid tying up threads and sockets.
Q: Which layers need updating when I increase third-party request timeout?
A: Update the client library timeout, reverse proxy and load balancer idle/read timeouts, server framework limits, and any background job or platform timeouts so no layer times out first. Compute a single deadline at the start of the request, propagate it downstream, and increase third-party request timeout only after aligning these layers.
Q: Can I request more time from the provider using a query parameter?
A: Some APIs accept a timeout parameter (for example ?timeout=50000&url=…) that asks the provider for more time. Use that parameter only if the provider supports it and keep the requested value within your own deadline when you increase third-party request timeout.
Q: How should I implement retries when extending timeouts?
A: Retry only idempotent methods and use exponential backoff with jitter (for example 200ms, 400ms, 800–1200ms). When you add retries, increase third-party request timeout and set an overall deadline so retries do not exceed your total allowed time.
Q: What if my platform or provider enforces a hard execution limit?
A: If the provider or platform has a hard cap (Cloudflare around 100 seconds, Heroku router 30 seconds, or similar), raising your timeout locally will not help. Redesign long-running calls to use async patterns like background jobs, webhooks, or streaming instead of trying to increase third-party request timeout.
Q: How can I reduce the need to increase third-party request timeout in the first place?
A: Use caching, request only needed fields or paginate responses, and compress payloads to reduce work and network time. Prefer webhooks, background jobs, or streaming so you can avoid lengthening deadlines and only increase third-party request timeout when truly necessary.
Q: What should I monitor after changing timeouts to ensure stability?
A: After rollout, watch success rate, median and P95 latency, concurrency, queue length, and thread/socket usage, and log the requested timeout_ms versus actual durations. Set alerts for rising P95/P99 or resource saturation and be ready to roll back or adjust after you increase third-party request timeout if you see cascading failures.
Contents
