Slow-response monitoring needs two choices: the response time considered slow and the number of consecutive slow checks required before opening a performance incident.
The available thresholds are 1, 2, 3, 5, and 10 seconds. The available confirmation counts are 2, 3, 4, and 5 checks. The default is 3 seconds for 3 checks.
What response time measures
The recorded value covers the monitored HTTP request through receipt of the response headers, including connection work and followed redirects. It is not a browser page-load measurement and does not wait for every image, script, font, or client-side action.
Only successful availability checks can count as slow. A failed or timed-out request is handled by availability monitoring instead and breaks the consecutive slow-check sequence.
Choose the threshold
Review the Response Time chart and Detailed Logs over normal and busy periods. Choose a threshold that represents a meaningful customer-impacting change rather than an occasional small spike.
| Threshold | Typical use |
|---|---|
| 1 second | Fast API or health endpoint with consistently low latency |
| 2 seconds | Responsive application or website where moderate delay matters |
| 3 seconds | Balanced starting point for many public websites |
| 5 seconds | Variable hosting or a less latency-sensitive endpoint |
| 10 seconds | Only when long successful responses are expected and the availability timeout permits it |
A check counts as slow when its recorded response time reaches or exceeds the threshold.
Keep the threshold below the timeout
The availability timeout ends a request that takes too long. Set the slow threshold below the timeout when possible so there is room to record a successful-but-slow result.
If a request reaches the timeout first, it becomes an availability failure rather than slow-response evidence. A 10-second slow threshold is therefore not useful with a 10-second timeout.
Choose the confirmation count
- 2 checks reacts fastest but is more sensitive to short-lived spikes.
- 3 checks is the balanced default.
- 4 checks requires a longer sustained slowdown.
- 5 checks is the most conservative option for highly variable sites.
The approximate time to open an incident is the interval multiplied by the confirmation count:
| Interval | 2 checks | 3 checks | 5 checks |
|---|---|---|---|
| 1 minute | 2 minutes | 3 minutes | 5 minutes |
| 5 minutes | 10 minutes | 15 minutes | 25 minutes |
| 15 minutes | 30 minutes | 45 minutes | 75 minutes |
Actual timing can vary slightly with scheduling and request duration.
Recovery uses the same count
An open performance incident resolves after the configured number of consecutive later checks no longer meet the slow condition. Eligible Alert Channels can then receive a recovery notification.
Performance incidents do not change the monitor's Up status or availability percentage. If availability fails, the separate outage-confirmation process applies.
Recommended starting point
Start with 3 seconds and 3 checks. After observing normal response times, lower the threshold for consistently fast endpoints or raise it when normal traffic regularly approaches the default.