> ## Documentation Index
> Fetch the complete documentation index at: https://docs.godizzy.dev/llms.txt
> Use this file to discover all available pages before exploring further.
# Latency & Timeouts
> Inject high latency or return timeout errors to verify your agent degrades gracefully when a tool is slow or unresponsive.
An agent that handles a 500 correctly may still break when a tool takes 15 seconds to respond. Timeouts are different from errors: the client has to decide when to give up, and if your agent does not have a timeout configured — or does not handle it gracefully — it will hang, block downstream steps, or consume resources indefinitely.
GoDizzy gives you two ways to test this: inject latency to trigger the client's own timeout, or return a timeout-style error response immediately.
## Inject latency to trigger a client timeout
This approach tests whether your agent has a timeout configured and what it does when the timeout fires. GoDizzy holds the connection open for the configured latency range before responding. If your agent's timeout is shorter than the latency, the client drops the connection — GoDizzy never sends the response.
In your route collection, create a new routing rule. For an LLM tool or slow upstream API:
* **Method:** `POST`
* **Path:** `/completions`
Adjust the path to match whatever tool endpoint you want to test.
Choose **Mock** as the action. Set **Status** to `200` and provide a realistic response body — what the tool would normally return if it succeeded.
```json mock body theme={null}
{
"id": "cmpl_abc123",
"object": "text_completion",
"choices": [
{
"text": "This response was delayed.",
"index": 0,
"finish_reason": "stop"
}
],
"usage": {
"prompt_tokens": 12,
"completion_tokens": 6,
"total_tokens": 18
}
}
```
The body does not matter much here — the goal is to make the agent wait long enough that its timeout fires before this response arrives.
Set **Min latency** to `9000` ms and **Max latency** to `10000` ms.
If your agent has a 10-second timeout, this will trigger it on most requests. Adjust the range to match your agent's actual timeout setting.
GoDizzy picks a random delay within the min/max range for each request. Setting a range (rather than a fixed delay) lets you catch flaky behavior that only appears when the latency is near — but not always over — the threshold.
Your agent calls the tool endpoint. GoDizzy waits 9–10 seconds before responding. Depending on your agent's timeout:
* If the agent times out before GoDizzy responds, the agent receives a connection timeout error from the HTTP client.
* If the agent does not have a timeout set, it will wait indefinitely for the response.
### What the agent sees
The agent sends the request normally:
```http theme={null}
POST /completions HTTP/1.1
Host: your-collection.godizzy.dev
Content-Type: application/json
{
"model": "gpt-4o",
"prompt": "Summarize the following document..."
}
```
GoDizzy holds the connection for 9–10 seconds. If the agent's HTTP client has a timeout shorter than that, it closes the connection and the agent receives a timeout error — never seeing the mock response body.
## Return a timeout error immediately
This approach skips the wait and returns a 503 or 504 error response right away. Use this to test how your agent handles the error code — separate from testing whether it has a timeout configured.
In your route collection, create a new routing rule:
* **Method:** `POST`
* **Path:** `/completions`
Choose **Mock** as the action.
Set **Status** to `503` for a service unavailable response, or `504` for a gateway timeout. Paste an error body that matches what the real upstream would return:
```json 503 mock body theme={null}
{
"error": {
"code": "service_unavailable",
"message": "The upstream service is temporarily unavailable. Please try again later.",
"request_id": "req_timeout_f3a2"
}
}
```
Or for a 504:
```json 504 mock body theme={null}
{
"error": {
"code": "gateway_timeout",
"message": "The upstream service did not respond in time.",
"request_id": "req_timeout_f3a2"
}
}
```
Optionally add a small latency (e.g. min `200` ms, max `500` ms) to make the response feel more realistic.
Your agent receives the 503 or 504 immediately. This tests your agent's error-handling logic directly, without the real wait.
### What the agent sees
```http theme={null}
POST /completions HTTP/1.1
Host: your-collection.godizzy.dev
Content-Type: application/json
{
"model": "gpt-4o",
"prompt": "Summarize the following document..."
}
```
```http theme={null}
HTTP/1.1 503 Service Unavailable
Content-Type: application/json
{
"error": {
"code": "service_unavailable",
"message": "The upstream service is temporarily unavailable. Please try again later.",
"request_id": "req_timeout_f3a2"
}
}
```
## What to test
Regardless of which approach you use, look for the following behaviors:
* **Does the agent degrade gracefully?** It should acknowledge the failure and either retry or surface a clear error to the user — not hang or produce a partial response silently.
* **Does the agent have a timeout configured?** If you use latency injection and the agent never times out, it has no timeout. That is a gap to fix.
* **Does the agent retry on timeout or 5xx?** If it does, does it back off between retries? Does it have a retry limit?
* **Does the agent fall back to a different tool?** For example, if a primary LLM tool times out, does it try a faster model or a cached result?
* **Does the agent communicate the failure clearly?** A user-facing message like "I was unable to complete this request because the tool timed out" is better than silence or a confusing partial answer.
Combine both approaches in sequence: start with the error response mock to validate your agent's 503/504 handling logic quickly, then switch to latency injection to confirm the timeout is actually configured and fires at the right threshold.