Timeout

When a program requests something that isn’t located on the same device, it has to wait. For example, it queries another computer on the internet for a piece of information and waits for the reply. Usually the answer arrives within fractions of a second. But sometimes it doesn’t arrive at all, because the connection drops or the other computer is overloaded. So that the requesting program doesn’t get stuck forever, a maximum waiting time is set in advance. This period is called a timeout. Once it has elapsed, the attempt is considered failed, and the program continues with an error message.

Why endless waiting gets expensive

A program that is waiting blocks resources while it does so. It occupies memory and often an open network connection. As long as it’s stuck, it can’t process new requests. For a service with many users, this adds up quickly: thousands of hanging requests can bring down an entire server, even though the server itself is perfectly healthy.

This is precisely the cause of many major internet outages. A single slow component brings the services that depend on it to a halt. Those services in turn wait for responses themselves, and the standstill ripples through the system like a wave. Experts call this a cascading failure. Sensibly set timeouts are the simplest brake against it.

Choosing the right time limit is nevertheless tricky. If it’s too short, requests get aborted that would actually have succeeded. If it’s too long, it barely helps at all. That’s why developers rely on measured data: if 99 percent of all responses arrive within 200 milliseconds, one second is a reasonable threshold.

What happens when the time limit expires

Technically, the program starts a counter alongside the request. If the response arrives beforehand, the counter is discarded. If it runs out, the program triggers an abort. The request is then considered failed, even if the response does arrive a second later after all.

A new attempt often follows the abort. So that not all users retry at the same moment and finish off the already overloaded server for good, each attempt waits longer than the previous one. First one second, then two, then four. This procedure is called exponential backoff. After several failed attempts, the program finally gives up and shows an error message.

One important point is often overlooked: a timeout says nothing about whether the action actually failed to happen. The other computer may well have executed the transfer, and only the confirmation got lost. That’s why retries for critical operations must not simply book things twice. Such orders are marked with a unique number so the recipient can recognize and discard a second, identical order.

Timeouts in apps, AI services, and outage reports

In everyday life, you encounter a timeout as a loading bar that eventually flips into a message. “No connection to the server” or “The request took too long” are typical phrasings. Online banking has a related variant too: after a few minutes of inactivity, you get logged out automatically. That’s a session timeout, and it serves security, not stability.

With AI services, timeouts play an especially important role. A large language model needs several seconds of genuine computing time to produce a long answer. Standard limits of 30 seconds are often too tight there. Developers who access such models through an interface need to deliberately raise the limit. Alternatively, the response is streamed in piece by piece, so the connection is never idle.

That’s why the word keeps showing up in cloud providers' outage reports. Sentences like “Users saw elevated error rates and timeouts” describe exactly this situation: the service wasn’t down, it just responded too slowly. For investors and customers, this is a warning sign, since downtime often costs money under cloud contracts.