Monitor status and uptime
Understand monitor statuses in Servor — up, degraded and down — plus how uptime percentage is measured and how flapping is smoothed to avoid false alerts.
Every monitor reports one of three statuses — up, degraded or down — and tracks an uptime % over time. This page explains what each status means, how uptime is calculated, and how Servor avoids spamming you when a service flickers on and off.
If you haven't created one yet, start with create a monitor.
The three statuses
The check passed. The target responded correctly and within the expected time. This is the healthy state.
The check passed but something isn't quite right — for example a slow response. The service still works, but it's worth a look.
The check failed. The target didn't respond, returned an unexpected result, or timed out. This is what alerts and automatic incidents react to.
Up means everything's fine. Down means the check failed and needs attention. Degraded sits between the two: the service is reachable but underperforming — a useful early warning before a full outage.
Uptime percentage
Uptime % is the share of time a monitor was up over a given window (for example the last 24 hours, 7 days or 30 days). If a monitor was down for 15 minutes out of a 24-hour day, its uptime for that day is about 99.0%.
A few things worth knowing:
- Uptime is measured from the checks Servor actually ran, at your check interval. A shorter interval gives a finer-grained figure.
- Time in degraded is not the same as down — read the status history, not just the headline number, to understand what happened.
- The same uptime data feeds status page components, so your public page reflects real measured availability.
The 'nines'
Uptime is often quoted in "nines": 99.9% is about 43 minutes of downtime a month; 99.99% is about 4 minutes. Aim for a target you can actually meet — chasing an extra nine is expensive.
Why status doesn't flip on every blip
Networks are noisy. A single failed check can be a momentary packet loss, not a real outage — and if every isolated blip flipped a monitor to down and fired an alert, you'd drown in false alarms.
To prevent that, Servor confirms a change before committing to it. A monitor doesn't flip status on the very first check that disagrees with its current state — it waits for the change to hold across a few consecutive checks before it officially goes down (and again before it comes back up). This is sometimes called hysteresis: it takes a little more evidence to change state than to stay in it.
The practical effects:
- Fewer false alerts. A one-off failed check that immediately recovers won't wake you up.
- A short, natural delay. Because a change must be confirmed, a real outage is reported a little after the first failed check, not instantly — the trade-off for not being spammed.
- Recovery is smoothed too. A flapping service that recovers for one check then fails again won't be declared healthy prematurely.
Interval affects how fast changes confirm
Confirmation happens over consecutive checks, so a shorter check interval confirms a real change sooner. Very short intervals detect faster; longer intervals add a bit more delay before a status flips.
Reading the history
Open a monitor from your monitors in Servor to see its timeline of checks and status changes. Use it to tell apart a single spike (one degraded check, quickly back to up) from a sustained problem (repeated failures). For CPU, RAM and disk trends on a connected machine, see resource metrics.