Latency and faults
Real APIs are sometimes slow and sometimes broken. Mock Studio can add a delay to responses and make a response fail on purpose, so you can check that your app shows a spinner, times out, retries and reports errors properly.
Where the settings are
| Setting | Where | Applies to |
|---|---|---|
| Global delay (ms) | Project in the rail, under Global response settings | Every endpoint in the project |
| Base delay (ms) | Endpoint editor, Advanced settings, Latency simulation | Every response of that endpoint |
| Random jitter (ms) | The same place | Every response of that endpoint |
| Delay override (ms) | On a response card | That one response |
| Fault injection | On a response card | That one response |
All delays are in milliseconds. 1000 ms is one second.
How the delay is computed
For each request, the wait before the reply is:
delay = (Delay override, if set, otherwise Base delay)
+ Global delay
+ a random extra from 0 to Random jitter- Base delay is the endpoint's normal wait. Default
0. - Delay override replaces the base delay for one response. Leave it blank to use the base delay. An override of
0means no endpoint delay for that response. - Global delay is always added on top.
- Random jitter adds a different random extra to each request, from 0 up to the number you set, so timings vary like a real network.
Worked example. Global delay 100, base delay 800, jitter 200, and two responses: one with no override and one with a delay override of 3000.
| Response | Calculation | Wait |
|---|---|---|
| No override | 800 + 100 + (0 to 200) | 900 to 1100 ms |
| Override 3000 | 3000 + 100 + (0 to 200) | 3100 to 3300 ms |
The delay applies to the responses you wrote. The server's own replies are sent at once: the 404 for a path with no endpoint, the 401 from a required auth header, CORS preflight replies and proxied requests are not delayed.
Add a delay to an endpoint
Open the endpoint and expand Advanced settings below the responses.
Under Latency simulation, type a number in Base delay (ms), for example
2000.Optional: type a number in Random jitter (ms), for example
500.Select Send in the test row.
The response time shown by the tester now includes the wait. An active tag appears on Advanced settings while a delay, jitter or required auth header is on. The Slow endpoint template creates an endpoint with a 2 second delay already set.
To slow the whole project, open Project in the rail and set Global delay (ms).
Fault injection
A fault makes one response misbehave. Open a response card and choose an option under Fault injection. The card's header shows a tag naming the fault.
| Option | What the server does | What the client sees |
|---|---|---|
| No fault | Sends the response normally. | The response. |
| Drop connection | Closes the connection without sending anything. | A connection error, not a status code. |
| Empty response | Sends the status code with no body and no Content-Type. | The status with a zero-length body. |
| Malformed body | Sends the status code with cut-off, invalid JSON labelled as JSON. | A JSON parse error. |
| Hang (never respond) | Waits 2 minutes before replying. | Nothing, until the client's own timeout. |
Any delay is applied first, then the fault.
Drop connection
The server closes the connection without a reply, as happens when a network fails or a server crashes mid-request. Your app gets a connection error such as "connection reset" or "empty reply from server", and no status code.
With curl the result is an error instead of a response, such as:
curl: (52) Empty reply from serverIn the Live section the request shows RST in place of a status code, with the note Fault: connection reset.
Use it to check that your app tells "the server said no" apart from "the server could not be reached".
Empty response
The server sends the response's status code with an empty body and no Content-Type header. The response's own headers and the project's global headers are not sent.
Use it to test code that assumes a 200 always comes with data. A client that parses JSON without checking will fail on the empty body.
Malformed body
The server sends the status code with a Content-Type of application/json and a body that starts like JSON and then turns into random characters:
{"truncated": q8#Zr)1v…The body you wrote is not sent. Use it to test how your app handles a parse error from a reply that claims to be JSON.
Hang (never respond)
The server holds the request for 2 minutes, then sends the normal response. Most clients give up long before that, which is the point: use it to check that your app has a timeout and shows a sensible message when it expires.
curl --max-time 5 http://localhost:8080/ordersAfter five seconds curl stops with a timeout error (code 28) and no response.
A client with no timeout does receive the response after the 2 minutes.
Recipes
A service that is slow now and then. Choose Random / weighted. Give the normal response weight 9, and a copy of it with Delay override (ms) 5000 weight 1. About one call in ten takes five seconds.
Fail, then recover. Choose Sequence (round-robin) with three responses: the first with Drop connection, the second with status 503, the third a normal 200. A client that retries twice succeeds on the third attempt.
A broken reply for one customer only. Choose Conditional rules. Add a response with the condition Path param id equals 13 and the fault Malformed body. Every other id gets the fallback.
Response strategies explains the three strategies used here. For a guided plan, see Resilience testing and the Flaky payments sample project.
Turn faults off again
Set Fault injection back to No fault on each response. A faulty endpoint keeps misbehaving for every client until you do, including teammates and phones using the mock. If an app that worked yesterday now fails against the mock, look for a fault tag on the response cards and for Fault: notes in the Live section.