Slow-response alerts report a performance problem while a website is still reachable. They are separate from availability alerts, so a monitor can show Up while a performance incident is active.
What counts as a slow response
A check contributes to slow-response confirmation only when it succeeds and its response time is above the configured threshold.
If the request times out, fails DNS or TLS validation, or returns an unaccepted HTTP status, it is an availability failure instead of a successful slow response.
When a slow-response alert is created
Slow-response monitoring is off by default. When enabled, you choose:
- A threshold of 1, 2, 3, 5, or 10 seconds.
- A confirmation requirement of 2, 3, 4, or 5 consecutive slow checks.
The default is 3 seconds for 3 consecutive checks. After the selected number of successful-but-slow checks, Uptime Basics opens a performance incident and queues eligible Slow Response notifications.
Why consecutive checks are used
A single response-time spike can come from temporary network congestion, a cold application process, or short server load. Confirmation helps distinguish a sustained performance problem from one unusual check.
The time required depends on the monitor interval. Three consecutive slow checks take about 3 minutes at a 1-minute interval and about 15 minutes at a 5-minute interval.
When the recovery alert is created
After an active performance incident, later successful checks must remain at or below the threshold for the configured confirmation count. Uptime Basics then resolves the performance incident and queues eligible Response Recovered notifications.
An availability failure during this period is handled by the availability system; it is not counted as a healthy performance result.
Why the monitor still says Up
Up and Down answer whether the target is reachable under the monitor's availability rules. Slow-response monitoring answers whether successful responses are taking longer than the selected limit.
Keeping these states separate lets you distinguish:
- Up with normal response time: available and within the threshold.
- Up with a performance incident: available but repeatedly slow.
- Down: confirmed availability failure.
Delivery requirements
Performance notifications use the same monitor Alert Channels as outage notifications. Email or SMS must be enabled at the account and monitor levels, and the monitor must select a verified destination.
The incident is still recorded if a notification is queued, fails, or is suppressed. Notification delivery does not determine whether the performance incident exists.
Choose a useful threshold
Use the Response Time chart and Detailed Logs to learn the website's normal range. Select a threshold high enough to avoid routine variation but low enough to identify performance that would affect a visitor.
Keep the availability timeout above the slow-response threshold when possible. Otherwise, a request may reach the timeout and become an availability failure before it can be recorded as a successful slow response.