Connection timeout

Your server isn't replying. Requests get no response before the timeout window closes. Your site shows as Down in DomainDash.

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

A timeout and a connection refused error point at different problems:

• Timed out — no response at all. The browser waits, then gives up. Something is either not answering or dropping the request.
• Refused — an instant "no". The server is reachable and replies straight away to say nothing is listening on that port.

If the page fails the moment you load it, see connection refused instead.

Symptom

• DomainDash shows the site as Down
• Browser shows "This site can't be reached" with the code ERR_CONNECTION_TIMED_OUT after a long wait (typically 30+ seconds)
• Running curl -v --max-time 30 https://example.com hangs until it times out with "Operation timed out"

What it means

DomainDash sent a request and waited, typically 10 to 30 seconds, depending on which phase stalls, but received nothing back. Either the server accepted the TCP connection and then went silent, or the request never arrived because something on the network dropped it.

The usual causes are a server too overloaded to process requests in time, a deadlocked application or dependency, or a firewall that drops packets instead of refusing them (a "black hole" route). Once you know what's stuck, clearing it is usually quick.

A timeout is also different from a slow response, where the server replies but takes too long. With a timeout, no reply arrives within the window.

What you'll see

The browser reports that it waited and heard nothing back. The message is the same whatever the cause:

• 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 gives up after a long wait

Common causes

• Server CPU or memory is exhausted (CPU at 100%, or memory full and swapping), 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. The server accepts the request but doesn't process it in time
• An upstream dependency (database, cache, third-party API) is down or very slow, causing every request to queue and wait
• A firewall or cloud security group is set to drop traffic rather than reject it, often a misconfigured rule or an accidental "deny all". Packets arrive and are discarded, so the client waits instead of getting a refusal
• The check points at a port where no process is listening, and a firewall in front drops the attempt, so the connection hangs rather than being refused
• 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
• A broken route or an upstream network fault between the checker and your server drops the request before it reaches your application

How to fix

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

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

   A timeout hangs for 30 seconds and then reports "Operation timed out". If it fails instantly with "Connection refused", see the connection refused page instead. Note whether curl got as far as opening a TCP connection. If it did, the server accepted the connection but then went quiet, which points to an application-level hang rather than a network block.

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 quickest fix is to restart the application process, then investigate whether you need to scale up.

3. Check application and dependency health. Review recent application logs for stuck requests or error storms: errors, stack traces, and requests that logged a start but never logged a finish. A locked table or a long-running query can cause every request that touches it to queue up and time out. 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 sign of the cause. If you have upstream API dependencies, check those too.

4. Look for traffic spikes or a DDoS. Check your web server access logs, or your hosting provider's bandwidth graphs:

   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 stuck process (application server, database, queue worker), restart it:

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

   Then confirm the server replies within a few seconds:

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

How to verify

Confirm the fix:

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. After the first passing check the site page header reads Recovering, and once recovery is confirmed it reads Healthy. If uptime for the selected timeframe (24 hours by default) is under 97%, it reads Unstable until the figure recovers.

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