You dial someone's number. It rings. And rings. And rings. After about 30 seconds, you hang up. Nobody answered, no point waiting forever.
That decision to hang up after 30 seconds? That's a connection timeout.
In software, a connection timeout is the maximum time your application will wait to establish a connection with another service before giving up. Not the time to get a response, just the time to confirm the other side is even there and willing to talk.
This matters more than most developers realize. Here's a scenario: your web app calls a payment service. The payment service's server is down, not returning errors, just completely unreachable. Without a connection timeout, your app would wait. And wait. And wait. Meanwhile, the user is staring at a spinner. Your server thread is stuck. As more users hit the same codepath, more threads get stuck. Eventually, your entire application hangs because all threads are blocked waiting for a dead service.
A missing connection timeout is one of the most common causes of cascading failures in production systems. The fix takes one line of code. The outage it prevents can save your company hours of downtime.
Before any data is exchanged between a client and a server, they perform a handshake, a three-step process to establish a connection.
This entire handshake typically takes 1-100ms depending on network distance. If the server is in the same data center, it's under 1ms. If it's across the ocean, maybe 50-100ms.
The connection timeout is the maximum time you'll wait for that SYN-ACK. If the server never responds, because it's down, the network is broken, a firewall is blocking traffic, or the server is so overloaded it can't accept new connections, your client gives up after the timeout and throws an error.
This is an important distinction that many developers confuse:
| Timeout Type | What It Covers | Typical Value |
|---|---|---|
| Connection Timeout | Time to establish the TCP connection (the handshake) | 1-5 seconds |
| Read/Request Timeout | Time to receive a response after the connection is established |
Before your application sends a single byte of real data, the client and server perform a three-way handshake. The connection timeout governs how long the client will wait for this handshake to finish.
Walk through what happens when a connection timeout kicks in, and why it prevents cascading failures.
The default connection timeout in most clients is way too generous. Java's HttpURLConnection defaults to infinite, it will wait forever. Python's requests library also defaults to no timeout. That's asking for trouble.
Same data center (service-to-service): 1-2 seconds. If a service in the same network isn't responding within 1 second, something is seriously wrong. Waiting longer won't help.
2-3 seconds. A little more slack for the extra network hop.
3 questions - Score 80% to pass
What does a connection timeout protect against?
Service A calls Service B in the same data center. The connection typically establishes in 2ms. What's a reasonable connection timeout?
Your app has no connection timeout configured. The payment service goes down. What is most likely to happen?
| 5-30 seconds |
The connection timeout is almost always shorter than the request timeout. If the server isn't reachable, you want to know fast. But once connected, the server might legitimately need time to process your request.
Cross-region or external APIs: 3-5 seconds. International network paths can be slow, but anything over 5 seconds usually means the destination is unreachable.
Never: Use no timeout. Never. Not in prototype code, not in scripts, not anywhere. Always set a connection timeout.
If your connection timeout is too aggressive, say 100ms for a service across the Atlantic, you'll get false failures. The connection would have succeeded at 150ms, but you gave up too early. Users see errors for no reason.
If your connection timeout is 60 seconds, and the target service is dead, every request ties up a thread for a full minute before failing. Under load, you run out of threads in minutes and your entire application becomes unresponsive. This is the classic cascading failure pattern.
Look at your P99 connection time under normal conditions (most monitoring tools track this). Set your timeout to 2-3x that value. If connections normally complete in 200ms at P99, a timeout of 500ms-1s is reasonable.