When should a slow or timing out link be treated as a broken link?

What a timeout tells you and what it does not

A timeout means the checker stopped waiting. That could be a connection that never opened, a TLS handshake that stalled, or a server that accepted the request and never sent headers. It says nothing definite about the page itself. The causes span from a genuinely dead host, to a transient overload, to a firewall silently dropping packets from your checker's address range, to a destination that is simply slow for everyone including real visitors.

Compare that with a hard error. A 404 or a DNS resolution failure is a clear verdict you can act on immediately. A timeout is a question mark. Treating every timeout as broken floods the report with noise and trains people to ignore it; ignoring every timeout lets destinations that have truly vanished sit unnoticed for months. The way out is a written policy with explicit thresholds, retries, and a confirmation rule before anything gets labeled broken.

Keep reading: Why Broken Links Quietly Hurt Your SEO, Internal vs External Broken Links: Which to Fix First, How to Find Broken Links at Scale. See how LinkRotly helps you continuous broken link monitoring for websites.

Choosing thresholds that match reality

Separate the connect timeout from the read timeout. A few seconds is typically enough for the connection, because a healthy server accepts a connection quickly even when the page it serves is slow. Give the read timeout considerably more room, on the order of tens of seconds, since large pages, slow origins, and cold caches can legitimately take a while. Apply stricter limits to your own internal links, which you control and can fix, than to external destinations you can only observe. Related: What a 404 Does to a Visitor, and How to Soften It

Retries and confirmation matter more than the exact numbers. Retry a timed-out URL after a short delay within the same run, then again on the next scheduled run. Report the link as broken only once it has failed consistently across multiple checks spanning hours or a full day. Record the pattern along the way; a destination that times out at the same hour every day is almost certainly hitting a maintenance window or a backup job, not going offline for good. Related: How to Find Broken Links at Scale

Slow but alive destinations

A page that consistently takes many seconds to respond is not broken, but it is a poor experience for anyone who clicks your link, and it says something about the health of that site. Track response time per destination over time rather than as a single reading. A rising trend often precedes an outright failure, because neglected sites tend to degrade for a while before they disappear entirely, and that warning gives you time to find a replacement calmly. Related: Why Broken Links Quietly Hurt Your SEO

For slow external links, the decision is editorial. If the destination is a key reference with no substitute, keep it and monitor closely. If it is one of several sources for the same point, prefer the faster one. For your own slow pages, treat the finding as a performance ticket rather than a link ticket. Internal timeouts are almost always worth an immediate look, since they signal a server, routing, or deployment problem rather than a rotten link.

Writing the policy down

A reasonable default policy reads like this: connect timeout of a few seconds, read timeout in the tens of seconds, up to three attempts spaced out, and a broken verdict only after failures across at least two separate runs. Use different thresholds for internal and external links, and keep an exception list for known slow but important destinations that should never be flagged on timing alone. Document all of it so the people reading reports understand what a timeout label actually means. Related: Internal vs External Broken Links: Which to Fix First

In reports, give timeouts their own category instead of mixing them with hard errors. Show the time of the first failure, the number of consecutive failures, the last successful response, and the recent response time trend. That context lets a reviewer decide in seconds whether to replace the link, wait another cycle, or escalate to whoever runs the server, instead of guessing from a single red row with no history behind it.