Your application calls an external API.
Usually it responds in 300 milliseconds.
Today it takes 30 seconds.
Your users are staring at a loading screen.
This is why timeouts matter.
External Services Can Fail
Your application may depend on:
Payment APIs Email providers AI APIs Maps Shipping systems Authentication services
Even if your code is perfect, another service can become slow or unavailable.
Never Wait Forever
Every external request should have a reasonable timeout.
Otherwise, one slow dependency can consume application resources while users wait.
What Should Happen After a Timeout?
It depends on the operation.
For a non-critical analytics request, you might continue without it.
For a payment request, you need a much more careful flow.
For a temporary API failure, a retry may make sense.
Retries Need Limits
Automatically retrying a failed request sounds useful.
But retrying too aggressively can make an outage worse.
For example:
API fails ↓ Retry ↓ Fails ↓ Retry ↓ Retry ↓ Hundreds of requests
Use sensible limits and backoff.
Not Every Error Should Be Retried
A temporary network timeout might be retryable.
An invalid authentication key isn't.
A 400 caused by bad input usually doesn't become valid after three retries.
Design for Failure
Production applications should assume external services sometimes fail.
Your application should have a plan.
A timeout isn't just an error setting. It's part of your application's reliability strategy.