Error guide

Connection timeout (ETIMEDOUT)

The connection attempt got no answer at all and the client eventually gave up.

A connection timeout means the client tried to open a connection, received no response, and gave up after its timeout. The defining feature is silence: nothing refused it, nothing answered it, the packets went into the network and nothing came back.

Silence has a specific and short list of causes, quite different from a refusal. A firewall configured to DROP rather than reject produces exactly this. So does a host that is down, a routing problem, or a server whose listen backlog is full and is silently ignoring new connections.

The distinction that matters most for diagnosis is WHEN the timeout happened. A timeout before the connection was ever established means the path or the host is the problem. A timeout after the connection was established, while waiting for the response, means the server accepted the request and is slow — a completely different investigation. Many tools report both with the same message, which is how the two get confused.

Common causes

  • A firewall or security group dropping packets silently.
  • The host down, or the address wrong, so nothing is there to answer.
  • A routing problem between the client's network and the host's.
  • The server's listen backlog full under load, so new connections are ignored.
  • On-path interference — an intermediate device accepting the TCP connection and then discarding the traffic on it.
  • A timeout budget on the client too short for a genuinely slow but working path.

How to diagnose it

  1. Establish whether the connection was ever established: a handshake that never completed and a slow response are entirely different problems.
  2. Test from several networks — a timeout from one path and success from another points at the path, not the host.
  3. Trace the route to see where packets stop.
  4. Check security groups and firewall rules for DROP policies on the port.
  5. Check the host's load and connection backlog if the timeouts are intermittent and coincide with traffic.

Whose fault is it? The network in between

Genuinely ambiguous, and that is the point: a timeout is the one failure that can be caused by either end or by anything between them. Testing from a second network is usually the fastest way to find out which.

What monitoring sees

This is the hardest failure for any monitor to judge, because a monitor's own network trouble produces exactly this shape. Uptimely records whether the connection was ever established, so a timeout on a connection that was never established is classified as a connect-phase failure and treated with more suspicion than one where the peer was reached and answered slowly — the second commits, because slowness past a reached edge is something users experience. A worsening check is also re-run before it commits, and a failure that coincides with signs that the prober's own path is degraded is discarded as inconclusive and recorded as a gap rather than reported as an outage.

Related error guides

Terms used on this page

Questions

What is the difference between connection refused and connection timeout?

Refused is a fast, explicit rejection: something answered and said no, so the host is up. A timeout is silence: nothing answered at all, which can mean a dropped packet, a down host, or a routing problem.

Why do timeouts cause false alerts?

Because the monitor cannot tell your outage from its own network trouble — both produce identical silence. That is why serious monitoring re-checks, requires consecutive failures, and looks at whether the connection was ever established before believing a timeout.

One of the Uptimely HTTP and network error guides, written for the person who operates the server rather than the one refreshing the page. Something here read wrong to you? Email support@getuptimely.com.