A timeout means the monitoring request did not complete within the monitor's configured request budget. No usable HTTP response arrived before that budget ended.
A timed-out check is an availability failure. It is different from a slow-response event, which requires a successful response that arrived before the timeout.
What can consume the timeout
The measured request can include more than application processing. Time can be spent on:
- DNS resolution;
- opening the network connection;
- negotiating HTTPS/TLS;
- following redirects;
- waiting for a firewall, CDN, load balancer, or origin;
- generating the application response; and
- temporary regional routing problems.
The Error column may show timeout, while Failure Diagnosis explains that the site did not respond before the allowed limit.
Check whether it is one failure or an outage
One timeout row does not automatically change the monitor to Down. Uptime Basics requires regional and consecutive-failure confirmation before opening an availability incident.
- Open Detailed Logs.
- Find the timeout row and review its timestamp and latency.
- Read the Confirmation column.
- Compare nearby successful checks.
- Open the incident only if the monitor reached a confirmed Down state.
An isolated timeout between successful checks often indicates a temporary delay. Repeated region-confirmed timeouts require investigation.
Compare the timeout with normal response time
Available timeout settings are 5, 8, and 10 seconds. One-minute monitors are limited to 8 seconds; monitors running every five minutes or longer can use up to 10 seconds.
Use recent successful checks to decide whether the configured value is reasonable:
- If successful responses normally finish well below the limit, repeated timeouts suggest a real application, network, or access problem.
- If healthy responses regularly finish close to the limit, select the next supported timeout and investigate why the service is slow.
- If you only want a performance warning, enable Slow Response Alerts instead of making availability checks fail sooner.
Changing the timeout affects future checks only.
Check the target and infrastructure
Work through these areas in order:
Application and origin
Review server load, application logs, database waits, dependency calls, worker queues, and recent deployments around the failed timestamp. Test the exact monitored path rather than only the homepage.
CDN, firewall, and bot protection
Some security products silently delay or drop automated requests instead of returning HTTP 403. Review WAF events, rate limits, geographic rules, connection limits, and bot-management logs for the monitoring times and regions.
Redirects
Each followed redirect uses part of the same request budget. Remove unnecessary redirect hops and correct loops between HTTP/HTTPS, www/non-www, CDN, and origin rules.
Network and regional differences
Read the regional Confirmation details. A primary timeout that is reachable from the other regions does not count as a region-confirmed failed cycle. Failures from two or more regions indicate a broader issue than one route.
Request method and endpoint design
GET is the default and most compatible method. If the endpoint performs expensive work, consider a lightweight health endpoint that checks the dependencies needed to serve customers without generating a large response body.
Automatic fallback and protection
When a paid availability request times out or returns no HTTP status, Uptime Basics can try an IPv4 connection fallback while time remains. A www URL can also try the non-www hostname when enough request budget remains. These attempts do not extend the configured timeout indefinitely.
Repeated full-timeout failures can activate timeout protection. The service keeps your selected timeout for the primary availability check, while follow-up regional confirmation checks may use a shorter timeout. It can also reduce check frequency during a prolonged incident or pause a timeout-heavy monitor under account-level protection. Monitor Details displays an explanation when a safeguard is active, and normal configured scheduling restores after recovery where applicable.
What not to do
- Do not add an HTTP status to Accepted HTTP status codes; a timeout has no HTTP response to accept.
- Do not repeatedly pause and activate the monitor while diagnosing it.
- Do not set the timeout higher only to hide an overloaded site.
- Do not place credentials in the monitored URL while testing a protected endpoint.
When to contact Support
Contact Support when repeated timeouts continue even though the exact endpoint is healthy from multiple external networks and its access controls allow monitoring.
Include the monitor name, URL, configured interval and timeout, failed timestamps, regional Confirmation summary, and any relevant non-secret firewall result. Never include passwords, private keys, verification codes, or complete authorization headers.