How to Increase API Gateway Timeout (By Provider)
If a request to your API is timing out before your backend finishes processing, the fix usually involves raising a timeout value in your gateway or proxy configuration — but where you change it depends entirely on which gateway you're using. There's no single global setting; AWS API Gateway, Nginx, Cloudflare, and Kong each expose timeout controls differently, and some have hard ceilings you can't exceed no matter what you configure.
Below is how to raise the timeout on the most common gateways, followed by what to check before you assume a longer timeout is actually the right fix.
AWS API Gateway
AWS API Gateway (REST APIs) has a hard-coded maximum integration timeout of 29 seconds. This is not configurable past that limit — it's enforced at the platform level regardless of your Lambda or backend timeout settings.
To increase it up to the 29-second ceiling:
- Open the API Gateway console.
- Select your API, then the specific method (GET, POST, etc.).
- Go to Integration Request.
- Set Timeout under advanced settings, in milliseconds (max
29000). - Redeploy the API to the relevant stage.
Via AWS CLI:
aws apigateway update-integration \
--rest-api-id your-api-id \
--resource-id your-resource-id \
--http-method POST \
--patch-operations op=replace,path=/timeoutInMillis,value=29000If your backend genuinely needs more than 29 seconds, API Gateway is the wrong layer for synchronous requests — you'll need to move to async patterns (return a job ID immediately, poll or use webhooks/SNS for the result) or front the API with an Application Load Balancer instead, which supports much longer idle timeouts.
HTTP API Gateway (AWS, newer version)
HTTP APIs (the newer, cheaper AWS API Gateway type) have the same 29-second cap. There's no workaround via configuration — the limit is identical to REST APIs.
Nginx
If Nginx sits in front of your API as a reverse proxy, timeouts are controlled in the server block:
location /api/ {
proxy_pass http://backend;
proxy_connect_timeout 60s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;
}proxy_connect_timeout— time to establish connection to upstream.proxy_send_timeout— time between writes to upstream.proxy_read_timeout— time to wait for a response from upstream. This is usually the one that matters for slow backends.
Reload with nginx -s reload after editing. Nginx has no hard cap — you can set these to several minutes if needed, but very long timeouts tie up worker connections, so pair this with rate limiting.
Cloudflare
If you're using Cloudflare in front of your origin, the platform enforces a 100-second timeout on the free and pro tiers for HTTP requests before returning a 524 error. This is not adjustable on those plans. Enterprise plans allow raising it via Cloudflare support, but there's no self-service dashboard toggle.
Workarounds without an enterprise plan:
- Return a fast acknowledgment response and process the work asynchronously.
- Use WebSockets or Server-Sent Events for long-running operations instead of a single blocking HTTP request.
- Move slow endpoints to a subdomain not proxied through Cloudflare (DNS-only/grey cloud).
Kong
Kong exposes timeouts per service:
curl -X PATCH http://localhost:8001/services/my-service \
--data "connect_timeout=60000" \
--data "write_timeout=60000" \
--data "read_timeout=60000"Values are in milliseconds. read_timeout is again the one that most often needs raising for slow upstream responses.
Azure API Management
Azure APIM has a default backend timeout of 30 seconds (240 seconds for consumption tier without customization). You can override it with a policy:
<policies>
<inbound>
<base />
<set-backend-service timeout="120" />
</inbound>
</policies>Timeout is in seconds and applied at the operation or API level via the policy editor.
Before you just raise the timeout
A longer timeout treats the symptom, not the cause. Before increasing it further, check:
- Is the backend actually slow, or hanging? A request that takes 45 seconds every time is a performance problem, not a timeout problem. Profile the slow endpoint first.
- Are you doing synchronous work that should be async? File processing, report generation, and long-running AI calls are usually better handled with a "submit job, poll for result" pattern than a single long-held HTTP connection.
- Is streaming a better fit than one big blocking response? For LLM calls or large payloads, streaming the response as it's generated avoids the timeout question entirely — the client gets data immediately instead of waiting for the full result.
This last point matters a lot if you're building on top of Claude or another LLM API. Long generations can legitimately take 30–60+ seconds, which collides directly with gateway limits like AWS's 29-second cap. If you're routing Claude access through your own gateway and hitting these walls, using a service that handles streaming natively removes the problem instead of working around it. SubToAPI turns your Claude access into an HTTPS API with built-in streaming support, so long responses arrive as they're generated rather than requiring you to hold a single request open until completion. See the quickstart or the messages docs for how streamed responses are structured.
questions
What's the maximum timeout for AWS API Gateway? 29 seconds for both REST and HTTP APIs. This is a hard platform limit and cannot be increased through configuration — you need an async pattern or a different routing layer (like an ALB) for longer operations.
Why does my API still time out after I increased the gateway timeout? Check every layer in the request path: client-side fetch/axios timeout, load balancer idle timeout, CDN timeout (e.g., Cloudflare's 100s cap), and the gateway itself. The shortest timeout in the chain wins, regardless of what you set elsewhere.
Is increasing the timeout the right fix for a slow API? Usually not long-term. It buys time for genuinely slow-but-necessary operations, but if the same endpoint consistently needs 30+ seconds, moving to async processing or streaming the response is more reliable than repeatedly raising timeout ceilings.