A slow website and an unavailable website are different conditions. A monitor can remain Up while recording a slow response because the website still returned an accepted response before the configured timeout.
When a website is slow
A result can count toward a slow-response incident when all of these are true:
- The availability check succeeds.
- Slow-response alerts are enabled for the monitor.
- The measured response time meets or exceeds the selected slow-response threshold.
- The configured number of consecutive slow checks is reached.
The resulting incident is a performance incident. It helps identify sustained slowness without incorrectly reporting the website as unavailable.
When a website is unavailable
An availability check fails when Uptime Basics cannot obtain an accepted response under the monitor's settings. Examples include:
- The connection times out.
- DNS resolution fails.
- A connection or TLS handshake cannot be completed.
- The final HTTP status is not accepted by the monitor.
- A redirect cannot be followed successfully.
One failed check is evidence, not a confirmed outage. A monitor changes to Down only after the availability confirmation policy is satisfied.
The timeout is not a slow-response threshold
The Timeout is the maximum wait for an availability response. Reaching it produces a failed availability check.
The Slow response threshold evaluates a successful check. For example:
- A response in 4.2 seconds with an 8-second timeout and a 3-second slow threshold is successful but slow.
- A request that reaches the 8-second timeout is a failed availability check, not a successful slow check.
For useful separation, choose a slow-response threshold below the monitor timeout.
Can both incident types exist?
Availability and performance are tracked separately. Sustained successful-but-slow results can open a performance incident. Confirmed failed results can open an availability incident and change the monitor to Down.
The dashboard status reflects availability. Use Monitor Details, Response Time, incident history, and alerts to understand performance separately.
What to review when users report slowness
- Open Monitor Details and select the relevant time range.
- Review the Response Time chart for sustained increases or isolated spikes.
- Open the performance incident, if one exists.
- Review Detailed Logs for timestamps, response times, HTTP codes, and errors.
- Compare the slow-response threshold with normal response times and the availability timeout.
An isolated slow result may be temporary. Requiring consecutive slow checks reduces alerts caused by one brief network or server delay.