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
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.
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.
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:| Field | Value |
|---|---|
| Min latency | 200 ms |
| Max latency | 500 ms |
Simulate a near-timeout scenario
Push the delay close to your agent’s configured timeout to see how it behaves at the boundary:| Field | Value |
|---|---|
| Min latency | 9000 ms |
| Max latency | 10000 ms |
Simulate a fully timed-out tool
Set the delay beyond your agent’s timeout threshold to guarantee every request times out:| Field | Value |
|---|---|
| Min latency | 15000 ms |
| Max latency | 15000 ms |
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:
| Field | Value |
|---|---|
| Status code | 429 |
| Min latency | 800 ms |
| Max latency | 2000 ms |
| Body | {"error": "rate_limited", "retry_after": {{$randomInt(5,30)}}} |
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.