Connection timeout

Your server isn't replying at all. Requests vanish without a response until the timeout window closes. Your site shows as Down in DomainDash.

A connection timed out means the browser (or DomainDash) tried to reach your site, waited for a reply, and got nothing back before the wait window ran out. The request didn't bounce, it vanished. Chrome shows this as ERR_CONNECTION_TIMED_OUT (some places write it connection_timed_out) under the heading "This site can't be reached".

It's worth being clear about the difference from a connection refused error, because the two get muddled and they point at opposite problems:

• Timed out — no response at all. The packets disappear into the void. You sit and wait, then the browser gives up. Something is either not answering or silently swallowing the request.
• Refused — an instant "no". The server is reachable and replies immediately to say nothing is listening on that port. The failure is fast, not a wait.

If the page fails the moment you load it rather than hanging first, you're looking at a refusal — head to connection refused instead.

Symptom

• DomainDash marks the uptime check as Down with error code connection_timeout
• Browser shows "ERR_CONNECTION_TIMED_OUT" or "This site can't be reached" after a long wait (typically 30+ seconds)
• Running curl -v --max-time 30 https://example.com hangs until it eventually times out with "Operation timed out"
• Unlike a connection refusal, there is no instant failure. The request disappears without a reply

What it means

A timeout means DomainDash sent a request and waited (up to roughly 10–30 seconds) but received nothing back. This is the opposite of a connection refused error, where the server replies immediately with "no". Here, the server either accepted the TCP connection and then went silent, or the request never arrived at all because something on the network swallowed it.

The root cause is almost always one of three things: the server is overwhelmed and can't process requests in time, an application or dependency is deadlocked, or a firewall is silently dropping packets instead of actively refusing them (a "black hole" route).

This is also different from a slow response: a slow response means the server eventually replied but took too long. A timeout means no reply arrived within the window at all. Pinning down which of the three is at play is most of the battle. Once you know what's stuck, clearing it is usually quick.

What you'll see

A timeout looks different depending on where you're standing. It helps to separate the message on the screen (client side) from what's actually broken (server side).

Client side: the message in the browser

This is what your visitors and you see in the browser. It's a symptom, not a cause: the browser is just reporting that it waited and heard nothing back:

• Chrome / Edge — "This site can't be reached", with the code ERR_CONNECTION_TIMED_OUT (sometimes written connection_timed_out)
• Firefox — "The connection has timed out"
• Safari — "Safari can't open the page because the server stopped responding"
• A spinning tab that eventually gives up after a long wait, rather than failing instantly

The key tell is the wait. A timeout always involves a delay: the browser hangs, then fails. If the error appears the instant you hit enter, that's a refusal, not a timeout.

Server side: what's actually wrong

The browser message is the same regardless of the underlying cause, so the real work is on the server. A timeout almost always traces back to one of these:

• A firewall dropping packets silently. A misconfigured firewall rule or cloud security group set to drop (rather than reject) traffic creates a "black hole": packets arrive and are quietly discarded, so the client waits forever instead of getting a refusal.
• The server overloaded or too slow. CPU pegged at 100%, memory exhausted and swapping, or the application deadlocked on a long-running query, the request is accepted but never gets processed in time.
• Nothing listening on the port (or the wrong port). If the check points at a port where no process is bound, and a firewall in front swallows the attempt, the connection hangs rather than being refused outright.
• Routing or network issues. A broken route, a congested link at the provider, or an upstream network fault between the checker and your server can swallow the request before it ever reaches your application.

Common causes

• Server CPU or memory is exhausted, so the OS can't schedule the request in time
• Application is deadlocked or blocked on a long-running database query or external API call
• An upstream dependency (database, cache, third-party API) is down or very slow, causing every request to queue and wait
• A firewall or security group is silently dropping packets rather than actively refusing them, often a misconfigured rule or an accidental "deny all" added to a cloud security group
• The server is under a distributed denial-of-service (DDoS) attack or unusual traffic spike
• An oversaturated network link, where the server's provider is experiencing congestion

How to fix

1. Confirm it's a timeout, not a refusal. Run:

   curl -v --max-time 30 https://example.com

   A timeout hangs silently and then fails after the time limit expires. If it fails instantly with "Connection refused", see the connection refused page instead.

2. Check server CPU and memory. SSH in and run:

   top

   Look for CPU at or near 100%, memory so full the system is swapping, or any process in D state (uninterruptible sleep, usually waiting on disk I/O). For a quick five-second snapshot:

   vmstat 1 5

   If the server is overloaded, the most immediate fix is to restart the application process and investigate whether you need to scale up.

3. Check application and dependency health. Review recent application logs for stuck requests or error storms. For PostgreSQL, find long-running or waiting queries:

   SELECT pid, now() - pg_stat_activity.query_start AS duration, query
   FROM pg_stat_activity
   WHERE state = 'active'
   ORDER BY duration DESC;

   For MySQL: SHOW PROCESSLIST;. A query running for several minutes is a strong indicator.

4. Look for traffic spikes or a DDoS. Check your web server access logs:

   tail -100 /var/log/nginx/access.log

   A flood of requests from a small number of IPs, or a sudden spike in overall request rate, can exhaust the server's connection pool. Consider enabling rate-limiting, or temporarily blocking the source ranges at your firewall or CDN.

5. Restart and re-verify. Once you've identified the cause, restart the affected process:

   sudo systemctl restart nginx
   # or your application process manager, e.g.
   pm2 restart all

   Then confirm the server replies promptly:

   curl -v --max-time 10 https://example.com

How to verify

Confirm the fix held, so your visitors are getting a reply, not a spinning tab:

1. Run curl -v --max-time 10 https://example.com. It should return a response within a few seconds.
2. Load the site in a fresh browser window. It should load normally.
3. Open the site in DomainDash. It re-checks on its normal schedule, so once your server is replying again the next scheduled uptime check clears the incident and the status returns to Healthy on its own. There's nothing to click.

Related

• Connection refused — if the request fails instantly rather than hanging
• Site responding slowly — if the server does eventually reply, but takes too long
• Site is down — if you're not sure which uptime issue you have
• Uptime — how DomainDash runs uptime checks