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.
Latency injection
Error response
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.Create a routing rule for the tool endpoint
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. Set the action to mock
Choose Mock as the action. Set Status to 200 and provide a realistic response body — what the tool would normally return if it succeeded.{
"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
}
}
Set the latency range near the client's timeout threshold
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.
Run your agent and observe the timeout behavior
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:POST /completions HTTP/1.1
Host: your-collection.godizzy.dev
Content-Type: application/json
{
"model": "gpt-4o",
"prompt": "Summarize the following document..."
}
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.Create a routing rule for the tool endpoint
In your route collection, create a new routing rule:
- Method:
POST
- Path:
/completions
Set the action to mock
Choose Mock as the action.
Configure a 503 or 504 error response
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:{
"error": {
"code": "service_unavailable",
"message": "The upstream service is temporarily unavailable. Please try again later.",
"request_id": "req_timeout_f3a2"
}
}
{
"error": {
"code": "gateway_timeout",
"message": "The upstream service did not respond in time.",
"request_id": "req_timeout_f3a2"
}
}
200 ms, max 500 ms) to make the response feel more realistic. Run your agent and observe error handling
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
POST /completions HTTP/1.1
Host: your-collection.godizzy.dev
Content-Type: application/json
{
"model": "gpt-4o",
"prompt": "Summarize the following document..."
}
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.
