Add latency and errors to your mock API
Your mock API can be slow, flaky and rate limited on demand, so the error handling you wrote actually runs before it ships.
- Delay in milliseconds
- Error rate per service
- Per endpoint too
- Same settings locally
Service settings
What is latency and error simulation on a mock server?
Deliberately making the API slow or unreliable so your app has to cope. A delay in milliseconds and an error rate as a percentage, set on the whole service or on a single endpoint.
There is no proxy to put in the middle and no chaos tooling to install. The next request is already slow, or already failing.
You only ever test the happy path
You already know what a 200 looks like. What you cannot easily produce is the timeout, the 503 and the sudden rate limit your retry and fallback code is supposed to survive, because the real API is reliable in development and breaks in production instead.
Turn failure on and you hit those paths on your own machine. The spinner that never stops is a lot cheaper to find there than in production.
Fixed latency
Add a delay to every response and watch what your loading states and timeouts really do on a slow network.
Error rate
Set the share of requests that fail, so your retry and fallback code runs while you are still writing it.
Per endpoint
Slow down or break one route and leave the rest fast, so a test targets exactly the failure you care about.
Questions
- Can I fail only one endpoint?
- Yes. Latency and error rate can be set for a whole service or for a single endpoint, so the rest of the API stays fast and healthy.
- Does a delayed request still count?
- Yes. A slow response is still a response, so it counts towards your plan's requests the same as a fast one.
- Can I do this without the hosted service?
- Yes. The engine is MIT licensed and takes the same settings from a configuration file, so you can produce the same failures locally or in CI.
Bring a spec. Get a mock server.
It costs nothing to start. Dedicated infrastructure when you need it.