Painfully familiar.
Composite stories of five bugs every QA team has met, all invisible on a fast laptop and all reproducible in ten seconds once you can slow the API on demand.
On a dev machine the API answers instantly, so the UI never spends time in its in-between states. Real users live in those states. These are composites of failures common enough that most teams will recognise them; none is a report of a specific incident.
A form button stays enabled while the request is slow. The user taps twice. Two orders. Reproduce: add a 5 s delay to the POST and tap twice.
The request fails but the error branch never clears the loader. Reproduce: force a 500 with a delay and watch whether the spinner ever leaves.
Typing "ab" then "abc": the "ab" response arrives last and overwrites the "abc" results. Reproduce: delay only the first request URL longer than the second.
The request never returns and the UI waits forever. Reproduce: a very long delay, then check for a timeout message and a retry.
A new account has no data and the page shows a blank white area. Reproduce: return an empty array.
Save each delay or failure as a named rule. Before a release, enable the group, click through the flows, and disable it again. It takes minutes and it checks the states users actually meet.
Create a rule that matches that URL pattern and set a delay in milliseconds. Other requests are untouched.
Tick the boxes. Sleep better.
Happy paths get tested. Failure paths get shipped. Use this checklist to force each API failure mode in minutes and make sure your UI handles it.
Create a free ProxyCeptor account to mock, delay, block and rewrite API traffic, then share the same rules with your team.