Why inject latency
Real tool APIs are not always fast. Testing your agent only against instant responses misses an entire class of production failures:- Retry logic — Does your agent retry on a slow response, and does it back off correctly?
- Timeout handling — If a tool takes 10 seconds, does your agent time out gracefully or hang?
- Cost of slow tools — Slow tool calls can cascade into longer end-to-end agent runs. Measuring this in a controlled environment lets you tune budgets before it affects real users.
- Graceful degradation — Can your agent fall back to a cached result or a simpler strategy when a tool is sluggish?
How it works
Each mock response has two latency fields:- Min latency (ms) — The minimum delay, in milliseconds.
- Max latency (ms) — The maximum delay, in milliseconds.
[min, max] and waits that many milliseconds before sending the response.
The delay is randomized on every request. If you set min to
200 and max to 500, one request might wait 214 ms and the next might wait 487 ms. This variability is intentional — it more accurately reflects real-world network and service jitter than a fixed delay.0 to disable latency and return the mock response immediately.
Configure latency on a mock rule
1
Open the mock rule editor
Navigate to your route collection, find the rule you want to add latency to, and open the rule editor. The rule must have its action set to Mock — latency only applies to mock rules.
2
Set the min and max latency
Enter values in the Min latency (ms) and Max latency (ms) fields. Both values must be non-negative integers, and min must be less than or equal to max.
3
Save
Click Save. GoDizzy creates a new version of the mock response with the updated latency range.
Examples
Simulate normal but variable API response time
Use a moderate range to exercise retry policies that should only trigger on true timeouts, not normal slowness:
Your agent sees a realistic 200–500 ms response time. Retry logic that triggers under 1 second will fire incorrectly, revealing a misconfigured threshold.
Simulate a near-timeout scenario
Push the delay close to your agent’s configured timeout to see how it behaves at the boundary:
If your agent has a 10-second timeout, some requests will succeed just under the wire and others will time out. This reveals race conditions in your timeout-handling code.
Simulate a fully timed-out tool
Set the delay beyond your agent’s timeout threshold to guarantee every request times out:
Setting min and max to the same value produces a fixed delay. Use this when you need every request to fail in exactly the same way, such as in a regression test for graceful degradation.
Simulate a rate-limited response with realistic backoff delay
Combine latency with a429 status code to test both the error handling and the timing of your agent’s retry-after logic:
Use cases by scenario
Tune retry policies
Inject a delay that is longer than your agent’s retry threshold. Confirm retries fire when expected and not on fast responses.
Test timeout handling
Set min/max near or beyond the agent’s configured timeout. Verify your agent does not hang and returns a sensible error.
Measure cascading cost
Run a realistic latency range across all tool rules and benchmark end-to-end agent run time. Use the data to set per-tool latency budgets.
Reproduce flaky tool behavior
A wide min/max range (for example,
50–3000 ms) mimics the jitter of an unstable third-party API without relying on real infrastructure.