All docs
Monitoring & alerting
The health score
Every server gets a health score from 0 to 100. This page explains how to read it: where the number comes from, what the seven categories weigh, what confidence and coverage mean, and how a lost point turns into a recommendation or an alert you can act on.
Reading the number
The score is deterministic. The same facts always produce the same number, and every point lost is traceable to one named rule. There is no hidden averaging and no machine-learning guess behind it.
| Score | Rating |
|---|---|
| 100 | Perfect |
| 95–99 | Excellent |
| 90–94 | Very Good |
| 80–89 | Good |
| 70–79 | Fair |
| 60–69 | Needs Attention |
| 40–59 | Poor |
| 0–39 | Critical |
The methodology is published as the Opservo Health Standard (OHS v1.0); the version is printed next to the score on the server page.
The seven categories
Each category starts at 100 and loses the points of every rule that fires. The overall score is a fixed-weight blend of the seven category scores, rounded to the nearest whole number.
| Category | Weight | Examples of what it checks |
|---|---|---|
| Performance | 25 % | CPU, load per core, I/O wait, memory and swap, PSI pressure, file descriptors |
| Security | 20 % | firewall, SSH root login and password auth, exposed ports, failed logins, security updates |
| Storage | 15 % | disk fill, inodes, days-to-full projection, SMART health, read-only mounts, failing disks |
| Reliability | 15 % | failed services, crash-looping containers, OOM kills, kernel errors, reboots |
| Maintenance | 10 % | pending reboot, pending updates, certificate expiry, end-of-life OS |
| Network | 10 % | packet loss, interface errors, DNS, conntrack table, listen-queue overflows |
| Configuration | 5 % | time sync, swap configured, duplicate IP |
A category can never go below 0 or above 100. The full catalogue of rules, thresholds and point values is in the Owner’s Guide and on the health standard page. This page does not repeat it.
Confidence, coverage and n/a
Not every check is equally certain, so every finding carries a confidence level.
- •High — a definitive fact. The firewall is off; the disk is 96 % full.
- •Medium — a strong but single-sample or derived signal. One CPU reading at 97 %.
- •Low — a heuristic. A process that looks suspicious; a possible memory leak.
A category’s confidence is the lowest confidence among the findings that fired in it. A category that ran all its checks and found nothing is high confidence. A category with no data at all is low confidence.
Missing data never costs points. If the agent on a server does not report a metric yet, the rules that need it stay dormant and the category scores 100. To keep that honest, the server page shows coverage: the share of the rule catalogue that had data in this evaluation, for the whole server and per category. A category with no data reads No data yet rather than a number. As the agent updates and reports more facts, dormant rules switch on by themselves and coverage rises.
Every lost point is explained
Open a server and click any category in the Health panel. Each finding shows the rule that fired, the metric it inspected, the threshold, the current value, the points it cost, its confidence, and a fix. Where the fix is a shell command, it is shown ready to run. Findings are sorted so the highest impact and easiest fixes come first.
Where you see it
- •The fleet view on the home page has a Health column you can sort by. Green is 90 and above, amber 70–89, orange 40–69, red below 40. A server that has not reported yet shows a dash.
- •The server page Overview tab has the Health — OHS panel: overall score, coverage, a trend sparkline, and the seven categories. Click a category to see what fired and why.
- •The Issues page lists every open finding across all servers in one place, with Dismiss, Resolve with AI and manual fix actions.
From finding to recommendation to alert
After every heartbeat Opservo re-runs the engine on the latest snapshot. Three things happen:
- 1.Findings are reconciled into the server’s recommendations by a stable fingerprint. A finding that is still true is updated in place; one that no longer applies is removed.
- 2.Critical and warning findings become alerts on the same fingerprint, so you can see when a condition first appeared and get notified once per distinct problem. Info findings stay in the issue list only.
- 3.Alerts that are new since the last heartbeat are delivered to your notification channels.
Because the fingerprint is stable, a dismissal survives re-analysis. Dismiss a finding and it does not come back on the next heartbeat; it only reappears if it clears and then genuinely recurs.
Last updated 2026-10-01. Found a mistake? Email hello@getopservo.com.
Related