MediumReliability

Retries with no pause and no cap

One outage turns into a flood of retries from every open browser tab, which keeps the service down longer, runs up usage bills and can submit the same order or payment twice. Whether the app keeps working when something fails. Check it yourself with the steps below; our test adds what a script and a second account can find.

What it looks like

async function save(payload) {
  while (true) {
    try { return await api.post("/save", payload); }
    catch (e) { /* try again */ }
  }
}

A save function that retries a failed request immediately and forever, with no pause, no cap on attempts and no check on the kind of error.

What happens

One outage turns into a flood of retries from every open browser tab, which keeps the service down longer, runs up usage bills and can submit the same order or payment twice.

Where it shows up

Descriptive, not a verdict: builders and stacks whose defaults make this reachable, or that a public incident names. Each hub states the tool's own security features.

Check it yourself

Uses your builder's dashboard and your browser. No tools to install.

Open your app in Chrome, press F12 and choose the Network tab.
Find a request that saves or loads data, right-click it and choose "Block request URL".
Trigger the same action again (save the form or reload the list) and watch the Network tab for about a minute, then unblock the URL.

Bad result: the same request appears again and again in a steady stream, with no growing gaps between attempts, and does not stop until you close the tab. A good result is a handful of attempts with widening pauses, then a message.

What we check

We return HTTP 429 and server error statuses from the APIs the app depends on and measure how many times and how fast each client and server component retries. We also check whether retried writes create duplicate records, and the report shows the retry curve per endpoint.

Fix direction

Retry only errors that can succeed later (timeouts, HTTP 429, server errors) and cap the number of attempts. Wait longer after each attempt with a random spread, the approach cloud SDKs call exponential backoff with jitter. Give every write an idempotency key (a unique id the server uses to ignore repeats) so a retry cannot double a record or a charge.

Mechanism documented in: AWS SDKs and Tools Reference Guide: Retry behavior (verified 2026-09-21).

Covered by

Pre-launch check ($490, 48 hours) and Full audit ($1,900, 5 business days)

Both include a re-check after your fixes.

Compare packages

Related patterns

No idempotency on payment handlersPayments
A customer is charged twice after a network hiccup, or a replayed webhook tops up an account again and again for a single payment.
High
Errors swallowed, spinner never stopsReliability
When a request fails, users see a spinner that never ends or an empty list, assume the app is broken or their data is gone, and nobody on your side hears about it.
Medium
No rate limiting on sensitive routesReliability
A script can try thousands of passwords against your login form, hammer a form that sends emails or calls a paid API, or knock the app over, and the bill lands on you.
High
Race conditions on counters and balancesData integrity
Users can spend the same credits twice, book the last seat twice, or redeem a coupon more times than allowed, and the stored totals stop matching what was actually given out.
High

Questions

what is exponential backoff in simple terms

After a failed request, wait a little before trying again, and double the wait each time, with a random spread so that many clients do not all retry at the same moment. AWS describes this as exponential backoff with full jitter and uses it by default in its SDKs. It gives the failing service room to recover instead of burying it.

why did my app send the same request hundreds of times

A retry loop with no pause and no cap will fire as fast as the network allows until the request succeeds. Generated code often wraps a call in a loop or a recursive retry without a counter. Block the request in developer tools and watch the Network tab; a steady stream of identical requests is the sign.

can retries cause duplicate orders or payments

Yes. If a write times out after the server has already processed it, the retry creates a second record or a second charge. The fix is an idempotency key: a unique id sent with each write that the server uses to recognise and ignore a repeat. Stripe's API and most payment providers accept one.

Back to the catalogue, or run the self-check for your stack.