Slow-response alerts
Detect slow response times before slow turns into down.
A service doesn't have to go down completely to lose you users. Most outages announce themselves first: response times climb over days, a connection pool slowly fills, an index has been missing since the last deploy. A classic up/down check sees none of it — as long as a 200 comes back the service counts as healthy, whether the answer took 80 milliseconds or eight seconds. Slow-response alerts therefore introduce a third state: “degraded”, the moment measured response time crosses the threshold you set.
How it works
You set a response-time threshold per monitor. On every check UptimeAlien compares measured latency against it. If latency is above the threshold the monitor switches to “degraded” and you are notified through your alert channels — even though the status code is perfectly fine. Once response time drops back below the threshold, the monitor returns to “up”.
Your benefits
- Early warning before gradual degradation turns into an outage
- A dedicated threshold per monitor instead of one global value
- Catches slow responses that any up/down check considers healthy
- Makes performance regressions visible right after a deploy
- Uses the same alert channels as your downtime notifications
What you get
A third state between “up” and “down”, plus alerts as soon as latency gets out of hand.
Availability
Available on the paid plans.
“Slow” is the most common form of “broken”
Complete outages are rare and get noticed fast. The normal case is far quieter: a page that takes two seconds longer costs conversions without ever showing an error. An API answering just under the client timeout produces sporadic failures somewhere else entirely. To users none of this is distinguishable from an outage — to an up/down monitor it is, because technically everything responds correctly. Slow-response alerts work in exactly that gap.
Choosing the right threshold
A good threshold comes from the observed normal, not from a wish. Look at the monitor's history to see where response time usually sits, then set the threshold clearly above it — high enough that ordinary variance and the occasional outlier don't page anyone, low enough that real degradation stands out. Because the threshold applies per monitor, you can be strict with a static page and generous with a compute-heavy reporting endpoint without trading one against the other.
How it fits with the other monitor types
Slow-response alerts aren't a separate monitor type but a property of the monitors you already run. They apply wherever a response time is measured — HTTP/S checks as much as TCP, ping, DNS or an API monitor. In practice that means you configure your monitors once and get a statement about the quality of the answer on top of plain availability.
Frequently asked questions
What is a slow-response alert?
An alert triggered as soon as a monitor's response time crosses a threshold you set — even when the service still responds correctly. The monitor moves into the “degraded” state at that point.
What does the “degraded” status mean?
“Degraded” is a third state between “up” and “down”: the service is reachable and answering correctly, but slower than the threshold defined for it allows.
Does the threshold apply to all monitors at once?
No, the threshold is set per monitor. That lets you pick a strict value for a static page and a generous one for an expensive reporting endpoint.
What threshold should I pick?
Base it on the monitor's actual history and set it noticeably above the usual response time. Thresholds set too tight fire on normal variance; set too wide, they let real degradation slip through.
Is this included in the free tier?
Slow-response alerts are part of the paid plans. The free tier covers plain up/down monitoring.