For the complete documentation index, see llms.txt. Markdown versions of all docs pages are available by appending .md to any docs URL.
Timeouts
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 waits for upstream response 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 to wait for the next frame from the upstream response body. Time spent processing the response body, buffering response guardrails, transforming the response, or waiting for the client to receive data does not count. Use this setting to terminate a backend that stalls mid-stream, without capping how long a legitimately long upstream 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 upstream stream from a slow one. The responseIdleTimeout covers this gap by limiting the time that agentgateway waits for more data from the backend, 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