Which errors are worth retrying, and why do you need pauses?
Answer out loud or in your head first, then compare.
Answer
Retrying makes sense for a temporary problem, e.g. overload or certain connection errors. It usually won't fix bad data or missing permissions. After a failed attempt I wait and limit the number of further attempts. If the service provides Retry-After, I take that time into account.
The pauses can grow gradually, and a little randomness in their length prevents a thousand clients from retrying at exactly the same moment. I don't retry forever. I also check whether a library already retries the request, because stacked layers can multiply the traffic. Before retrying a write, I need to know I won't perform the effect twice.
Why it matters: Directly useful for model APIs and company integrations.
Possible follow-ups: What do you do if the service stays unavailable for an hour?
How did it go? Be honest — “Not yet” puts the question on your review list.
Start with
- B-P01 · What is Node.js, and how is it different from JavaScript in the browser? — JavaScript, TypeScript and Node.js
- B-P04 · What is a Promise? — JavaScript, TypeScript and Node.js
- B-P10 · What does TypeScript give you, and what doesn't it? — JavaScript, TypeScript and Node.js
Related questions
- Which errors are worth retrying? — JavaScript, TypeScript and Node.js
Practise in code
- Sensible request retries — runs tests in your browser
Further reading
- Microsoft Graph: Throttling guidance(opens in a new tab)Docs; accessed 22.10.2026. 429, Retry-After and controlling the call rate.