For the complete documentation index, see llms.txt. Markdown versions of all docs pages are available by appending .md to any docs URL.
Timeouts
Verified Code examples on this page have been automatically tested and verified.Set request and backend timeouts to prevent long-running requests.
Note
Agentgateway supports more than one configuration style. Where a feature can also be configured in the simplified llm or mcp modes, the examples on this page show each option in tabs. For more information, see Routing-based configuration.
Request timeoutsTimeoutA time limit for how long agentgateway will wait for a response from a backend before considering the request failed. Timeouts can be configured at the request or backend level. allow returning an error for requests that take too long to complete.
Note
Timeouts bound how long a request might take. To stop an intermediary from closing a long-lived MCP stream that is merely idle, use sseKeepAlive on the MCP backend instead. For more information, see Keep idle MCP streams alive.
Route Timeouts
You can configure these types of timeouts on a route.
| Timeout | Description |
|---|---|
requestTimeout | The time from the start of an incoming request, until the end of the response headers is received. Note if there are retries, this time includes the total time across retries. The response body is not included, so use responseIdleTimeout to bound gaps between body frames. |
backendRequestTimeout | The time from the start of a request to a backend, until the end of the response headers are completed. Note this time is per-request, so with retries this time is a per-retry timeout. Like requestTimeout, this retry process stops applying once the response headers arrive. |
responseIdleTimeout | The maximum time the response body can go without producing data. The window restarts on every body frame, so this range bounds the gap between frames rather than the total time a response might take. Use this setting to terminate a backend that stalls mid-stream, without capping how long a legitimately long response might run. The timeout is disabled when the field is unset or set to zero, and it never applies to responses that switch protocols, so upgraded WebSocket and CONNECT tunnels are not terminated by it. |
Because requestTimeout and backendRequestTimeout both stop measuring elapsed time once the response headers arrive, neither one places any bound on how long a response body might take, and neither can differentiate a stalled stream from a slow one. The responseIdleTimeout covers this gap by limiting the time that can pass between response body chunks, which matters most for streaming responses that are expected to run for a long time.
# yaml-language-server: $schema=https://agentgateway.dev/schema/config
mcp:
port: 3000
policies:
timeout:
requestTimeout: 1s
targets:
- name: everything
stdio:
cmd: npx
args: ["@modelcontextprotocol/server-everything"]Backend Timeouts
In addition to route level timeouts, you can configure per-backend timeouts within the backend configuration section.
| Timeout | Description |
|---|---|
requestTimeout | The time from the start of an HTTP request to a backend until the response headers are completed. |
connectTimeout | The time from the start of a TCP connection to a backend until the connection is established. |
# yaml-language-server: $schema=https://agentgateway.dev/schema/config
gateways:
default:
port: 3000
routes:
- backends:
- host: localhost:8080
policies:
http:
requestTimeout: 1s
tcp:
connectTimeout: 10s