A Practical Guide to Fetch API and Network Error Handling
Making HTTP requests from the browser with fetch, and handling the failures that happen on real networks, from timeouts to server errors.
Marcus Adeyemi
Where most projects go wrong
The usual mistakes:
- Treating every response as success
- Spinners with no timeout
- Automatically retrying payments or form submissions
- Swallowing errors silently
What good looks like instead
- Check response.ok before using the response
- Set timeouts on requests
- Show clear error states with a retry option
- Retry idempotent requests with backoff
- Log failures for monitoring
Why it matters
Many interfaces assume requests always succeed, so users see frozen spinners or lost data when networks are slow or servers fail.
The specs that matter
| Measure | Figure |
|---|---|
| fetch behavior | the promise rejects on network failure but not on HTTP error statuses |
| Checking status | response.ok is false for statuses outside 200 to 299 |
| Timeouts | implemented with AbortController and AbortSignal.timeout() |
| Retries | should use backoff and only for safe, idempotent requests |
Knowing when to hand it over
Tip: Bring in help when users report frozen interfaces or lost submissions on poor connections.
Where this comes from
- MDN Web Docs — Using the Fetch API
- MDN Web Docs — AbortSignal: timeout() static method
The figures and practices above come from the sources listed.
Working on something like this?
We take on Web Design & Development work for teams who want it done once, properly. Tell us what you are building and we will tell you honestly whether we are the right studio for it. Start a project.
Where to go next
Spotted something wrong? Report an error on this page. We correct on the page and say what changed.
