One poller guesses.
Oversight's probes agree.
The established monitors were designed around a central server and a poller that decides what is true. Oversight is built on distributed probe groups that vote, conditions that cascade from a single value up to a whole site, statistics that notice a slow drift long before it becomes an outage, and actions that do exactly the same thing every time. Nobody is woken unless something is really wrong, and when it is, one message explains the whole incident.
inbound ports. Every probe connects out over HTTPS and signs every request
to notice a dead probe and hand its sensors to the rest of its group
from a result arriving to a decision about what it means
message per rule, however much of the estate an incident takes down
Sensors join probe groups. Probes never own sensors.
In a traditional monitor a host belongs to one poller, proxy or probe. That one vantage point decides whether it is down, and when it has a bad day, so do you. Oversight turns the model round: a sensor joins probe groups in different places, every group forms its own view, and the state is decided by how many views agree.
Distributed probes
Small probes in your racks, your offices and the cloud, each connecting out over HTTPS. Nothing connects in, and a probe accepts no instruction between its own polls.
Probe groups
Sensors attach to groups, not to probes. A group shares its sensors between its probes, and a rendezvous hash moves only what has to move when one comes or goes.
Self-healing
Every probe heartbeats every ten seconds. A dead one is noticed within about two minutes and its work moves to its peers. A misbehaving probe is quarantined, but never the last one standing.
Consensus
One sensor, many vantage points, no duplicated objects. A group that did not report is left out of the count, never counted as healthy, and one group out of five cannot call an outage on its own.
From one value to a whole site, with a rule at every step.
What counts as critical is a property of the thing being watched, not of the monitoring system. So Oversight lets you say it at every level, and every level is decided the same way: worst first, and by how many of the things beneath it agree.
-
1
Each value
As many conditions as it needs, worst first: lists, ranges, patterns and changes. 1, 2 or 3 is WARN, and 5 is CRIT.
-
2
Each probe group
Every group forms its own view from those conditions, with a count of failed reads before it calls anything down.
-
3
The sensor
The views vote. ANY, SOME and ALL each map to any state, so SOME can be CRIT for a payment gateway and WARN for a mirror.
-
4
The device
Its sensors roll up under their own ANY, SOME and ALL. A server goes red on any failed check.
-
5
Group and site
The same rule again. A resilient switch fabric shrugs off one lost path, and twenty web servers only matter when several fail.
- The worst rule wins. Every rule is tested, so the order they were written in can never hide a critical behind a warning.
- Unknown is never downtime. No data is grey and labelled. It never drives a parent into alarm and never counts against availability.
- A typo wakes nobody. Invalid configuration is suspended after one attempt and flagged in the configurator, not paged.
- Fix a rule, fix the history. Raw readings are kept, so a corrected rule or unit is re-applied to the past.
The same incident gets the same response. Every time.
A rule says which states matter and what to do. A binding says where it applies: one object, or everything beneath it. Nothing is guessed and nothing is left to the order alerts happened to arrive in, so an action fires exactly when its rule says, to exactly who it names.
REST reaches anything with an endpoint.
Method, URL, headers and body are one template, with placeholders in every part and credentials sealed. A new integration is a template, not a development project.
- Launch an n8n flow with the whole incident as its input
- Launch a script that SSHes into a box and runs a command
- Restart a systemd service
- Call Home Assistant, PagerDuty or your own API
Built to behave predictably.
- One message or call per rule, drawn as a tree, worst first.
- Escalation is a second rule on a worse state, to a different audience or system.
- Recovery goes only to those who were told about the failure, and repeats are bounded.
- Schedules on local time. Outside its window a rule holds what is wrong and sends it when the window opens.
- Send any rule as a test, to its real recipients, with the result for each on the screen.
https://n8n.example.com/webhook/oversight
Authorization: Bearer ********
{"kind": "ALARM",
"rule": "NOC critical",
"count": 3,
"summary": "2 sensors in pve-02, 1 in pve-04",
"objects": [
{"site": "Primary DC", "group": "Proxmox",
"device": "pve-02", "object": "Cluster quorum",
"state": "CRIT", "previous": "OK"},
{"site": "Primary DC", "group": "Proxmox",
"device": "pve-02", "object": "Guests",
"state": "CRIT", "previous": "OK"},
{"site": "Primary DC", "group": "Proxmox",
"device": "pve-04", "object": "Ceph health",
"state": "WARN", "previous": "OK"}
]}
It understands clusters, storage, backups and telephony, not just ports.
Where an answer has to be worked out rather than read, a user function written by GEN reduces the response to plainly named values, and one fetch fans out into as many alarms as it deserves.
Proxmox VE cluster
Quorum, expected nodes, and online and offline nodes by name. A node missing from the list altogether still counts as offline.
Proxmox guests
Every VM and container as its own value with its own rule. Backup, migration and snapshot read as expected states, and a vanished guest reads as not found.
Proxmox Backup Server
The backup server watched alongside the cluster it protects, so a failing backup is an alarm, not a surprise at restore time.
Ceph
Health and raised checks, monitor quorum, OSDs up and in, placement groups not active and clean, and manager availability.
Asterisk ARI
Every endpoint and trunk, with a count of those down and their names in the alert. Name the trunks that must exist and one sensor watches just those.
The usual round trip signs in to your mailbox. Oversight's signs in to nothing.
The established email checks send through an SMTP server you name, then sign in to a mailbox to see whether the message arrived. Signing in is where the cost lies: IMAP or POP3 left switched on, a service account whose password lives in the monitoring system, and on modern hosted mail an app registered for OAuth2 or an exception carved out of MFA. For all that, it proves one direction.
Oversight sends from outside, straight to your MX, and your mailbox forwards the message back out through your own outbound route. It works with any mail system that can forward, signs in to nothing, and one test proves mail is both reaching you and leaving you.
Every established monitor can run a command on your host. Oversight's agent cannot.
The established monitors all document a way to run your own commands on the host: a UserParameter, an NRPE command, a local check, a script sensor. It is how their agents are extended, and it is why an agent that was meant to read the host can end up acting on it. Oversight's agent has no exec, no plug-ins, no custom-check hook and no write endpoint, and none will be added. It runs as its own unprivileged user, never as root.
It also does its own judging. The checks run on the host, where the context is, and what is served is a verdict: nothing wrong, or what is wrong and how badly, in words the person fixing it can act on.
- Extended by running things. Custom commands, scripts and plug-ins are the documented way to add a check.
- Figures out, judgement elsewhere. Most checks send values for thresholds on the server to judge, and a verdict on the host is left to your own scripts.
- Sometimes root. Checkmk's agent runs as root unless a commercial edition is set up otherwise.
- Read only, structurally. There is nothing in it that runs a command, so there is nothing to misconfigure into one.
- It remembers. A link that had carrier and lost it, a filesystem that was writable and is not, a port that listened for an hour and has stopped.
- It waits before it raises. A problem must hold before it alarms and clear for as long before it drops, so a scrub or a backup window never flaps.
- It answers when the host cannot. Every reply comes from what has already been sampled, so a hung NFS server never leaves a request waiting.
Anomaly detection usually means a band and a spike. Oversight looks for the drift.
The usual approach learns an average for each hour of the day and day of the week, draws a band around it, and raises an alert when a reading falls outside. Switched on across the estate, as one established monitor does by default, every sensor soon has an anomaly of its own, and the alerts are learnt to be ignored. Worse, it is looking for the wrong thing. A spike that reverts is the internet having a moment. The router whose memory creeps up for three weeks never leaves the band, because the band moves up with it.
Oversight was designed the other way round. It judges windows, never single readings, on several time scales at once, against thresholds measured from each sensor's own history, and it reports what it finds as a behaviour rather than a fault. It runs only on the sensors you choose, and it never competes with a real alarm.
Only where it is asked
One setting per sensor, off by default. A sensor nobody would act on contributes nothing but noise, so it is never analysed, never stored for it, and never has an opinion to give.
A threshold nobody chose
Three sigma is too tight for a jumpy line and too loose for a steady one. Oversight measures how restless each sensor normally is, per probe and per time scale, and judges departures in that sensor's own terms.
A ladder, not a band
Day, week, month, the same day of the week and the same week of the year, each against its own history. Scales that disagree in direction cancel, and a finding records which scales it was built from.
A state, not an alarm
ABNORMAL for a trend, UNUSUAL for an odd day. Both count as working, both have their own colour, and both are quieter than a warning. A notification can be attached if you really want one; by default there is none.
- Persistence, not magnitude. A single reading never produces a finding in either state. UNUSUAL needs an hour of windows out of place; ABNORMAL needs a movement held across days.
- Several measures must agree. A standard deviation, a robust spread and the trend of the mean each vote. A single statistic trips at its own rate forever, on a sensor doing nothing wrong.
- Every vantage point on its own. London and Frankfurt see different networks, so each probe keeps its own baseline, and a probe that is itself degrading shows up as one.
- Honest about what it does not know. Nothing is said until the history is enough to judge by, measured by how settled the figures are rather than by a number of days.
- Only the readings that mean something. Failed reads, draft rows and counter wraps are kept out, and a reading taken across an outage is never mistaken for one taken across a minute.
- Built for the report. Rollups keep everything a later statistic needs, for years, so the year-on-year comparison still answers after every raw reading has gone.
Nobody has to read a graph to know what is going on.
An experienced engineer can look at a week of readings and see a problem coming. Most people who receive an alert or pay for monitoring cannot. Oversight's AI reads the evidence for them and says, in plain British English, what has happened, what it probably means and how urgent it is. Nothing is lost by it: the full detail always follows.
An overview at the top of every alarm.
Tick "Use AI" on a notification rule and each message opens with a short written account of the incident, before the usual tree and detail. The other monitors keep their AI in a chat window or a console page, if they have it at all. Oversight puts it in the message that wakes you.
- It knows what the checks mean. A failed ping on a broadband line means the line is down. A STALE sensor may be the probe, not the device.
- It summarises, it does not investigate. It is given the alarm's own facts, never charts, logs or credentials, and says "likely" where it is inferring.
- An alarm is never late for it. If the overview takes more than 30 seconds, the message goes on time without one.
The broadband line BT-001 at Head Office has
stopped responding to ping, so the site has most
likely lost its internet connection. This failure
has persisted for four minutes and needs attention
now.
Head Office: CRIT
Broadband: CRIT
BT-001: CRIT
Ping: CRIT (no reply)
Reports for everyone who needs to know, without anything breaking first.
Daily, weekly or monthly on local time, a report reads the series you choose over the period just gone, sets it against the period before, and has AI write up what the data shows. The same readings serve the engineer, the web team and the board.
A power review for engineering
Load on every UPS, by hour and by day. One early report found a UPS whose load peaks overnight rather than in the working day, and is drifting down about 12 watts a day.
Website latency for the web team
Response and connect times from every location. One early report found a site hitting its 5 second timeout at 02:00 on five nights running, pointing at something scheduled.
Uptime for management
Availability and failures by cause for the services that matter, against the month before, in words rather than graphs. Time with no data is kept apart, never counted as downtime.
- Any series, to the finest level. A site, group, device or sensor, down to a single value, with up to twelve series in a report and an optional question answered first.
- The arithmetic is done first. Average, median, 95th percentile, trend and the busiest hours are worked out exactly. The AI interprets the figures; it is never asked to add them up.
- Honest about what it does not know. With no previous period it says so, and a sensor added part way through is not reported as having gaps before it existed.
- Charts, figures and your own look. One chart per unit, a table of key figures against the previous period, and per-tenant templates. Preview any report before it goes.
Your estate never leaves GEN.
Oversight's AI runs on models GEN hosts in its own datacentres. Alarm facts and report figures go to it and nowhere else: no third-party AI provider, no public cloud, and no log of what it was asked. The same service that watches your estate is the only one that ever reads about it.
Where the established monitors document how their AI works, it runs in someone's cloud. SolarWinds sends requests to its own platform and on to commercial model providers, and keeps prompts, outputs and logs under its own retention policy. The AI add-ons on the Zabbix blog send problems to Google's Gemini.
Monitoring data is a map for an attacker.
- It names everything. Hostnames, addresses, device makes and firmware, and which services answer on which ports.
- It shows the weak points. The firewall that is failing, the UPS on its last minutes, the backup that did not run.
- It says when. An alarm is, by definition, a note that something is down right now.
- It outlives the incident. Once sent to a hosted AI service it sits in someone else's logs, under their retention policy and their jurisdiction, for whoever reaches it there.
AI is switched on for each estate by GEN. Without it, reports still go with their figures and charts, and alarms are sent exactly as before.
Configure it once, and the tree does the rest.
Save your own templates
Get one check right, save it as a template, and fill in the rest of the rack from it. Notification templates repeat per object, in the shape each channel wants.
Cascading credentials
Set credentials once at the site and they flow down the tree field by field. A device can override its password and still inherit the site's SNMP community. Sealed at rest, held by probes in memory only.
Schedules that mean it
Office hours and maintenance windows at fifteen-minute resolution, correct through the clock change. A schedule on an object stops it being polled at all.
Your estate, your logo
The estate wheel shows every site, group and device at a glance with your logo at the centre, and tenant isolation is enforced in the data layer.
An API for everything it knows
State, readings, state changes, availability and charts, in JSON or CSV that Grafana reads as it comes. Read only, one key per integration, limited to a branch and to named addresses.
Oversight against the established monitors.
Every entry for another product is taken from that vendor's own documentation, checked on 16, 17, 19, 21, 22 and 23 September 2026. Where a vendor documents nothing either way, we say so.
| Oversight | Zabbix | SolarWinds | PRTG | Nagios | Checkmk | |
|---|---|---|---|---|---|---|
| Architecture | ||||||
| Checks belong to a group of probes, not one collector | Yes Sensors join probe groups. Probes share the work, and a dead probe's sensors move to its peers within about two minutes | Partly A host can be assigned to a proxy group, but one proxy monitors it at a time | Partly Each node is polled by one polling engine, with standby HA pools for failover | Partly A sensor belongs to one probe. Only a failover cluster monitors from every node | Not documented | No Each host is monitored by exactly one site |
| The state is decided by how many locations agree | Yes Every probe group votes. ANY, SOME and ALL map to a state per object, at every level | No Each host is watched by one proxy at a time. Proxy groups fail over, they do not vote | No Each node is polled by one polling engine. HA pools are standby, not voting | Partly A failover cluster shows Down (Partial) when nodes disagree. No quorum setting, and not for remote probes | Not documented No multi-poller voting documented | No Each host is monitored by exactly one site |
| Alerts you can believe | ||||||
| No data is kept apart from downtime, by default | Yes Grey, labelled, never counted as downtime. Coverage is reported beside availability | Not documented An Unknown trigger state exists. Its treatment in SLA figures is not documented | Not documented An Unknown node status exists. Its treatment in availability is not documented | Not documented A grey Unknown status exists. Its treatment in uptime reports is not documented | Not documented UNKNOWN and stale results exist. Their treatment in reports is not documented | Partly Configurable: UNKNOWN can be regrouped and unmonitored time shown as N/A |
| A corrected rule can be re-applied to past readings | Yes Raw readings are kept exactly and history is re-evaluated against the fix | Not documented | Not documented | Not documented | Not documented | Not documented Annotations reclassify periods in availability reports. Re-applying thresholds is not documented |
| One incident, one message | ||||||
| Many problems arrive as one message | Yes One message per rule, however much of the estate the incident takes down | Partly Trigger dependencies hold back dependent problems. Grouped messages are not documented | Partly Dependencies mark children Unreachable and hold their alerts. Grouped messages are not documented | Partly Templates can summarise events, except for Slack, Teams and HTTP actions | Partly Parent hosts mark children UNREACHABLE, which can be left unnotified | Yes Bulk notifications collect problems into one message, up to a set count |
| The message shows cause and consequence as a tree, worst first | Yes Site, group, device and the check beneath it that took it there | Not documented | Not documented | Not documented | Not documented | Not documented |
| A plain-English overview can lead the message | Yes Per rule. What happened, where, what it probably means and how urgent, with the full detail beneath. Never delays the alarm | Partly Community add-ons on the Zabbix blog send a problem to Gemini. None built in | Partly An AI chat assistant, in technical preview, answers questions about alerts. Not in the message | Partly Alarm Insights, in early access in the new interface, suggests fixes. Not in the message | Not documented An experimental natural-language helper adds and removes hosts. AI alert summaries not documented | Partly Explain with AI summarises an incident in the interface, in Checkmk Cloud only. Not in the message |
| The AI runs on the provider's own hardware, with no prompt logging | Yes GEN's own models in GEN's own datacentres. Nothing goes to a third party and no prompt is logged | No The community add-ons send problems to Google's Gemini | No Requests go to SolarWinds' cloud and on to commercial model providers. Prompts and logs are retained | Not documented Where Alarm Insights runs is not documented | Not documented | Not documented Explain with AI runs in Checkmk Cloud. The model behind it is not documented |
| Matrix and Rocket.Chat built in | Yes Both, alongside email, SMS, XMPP and REST as full HTTP request templates | Partly Rocket.Chat and webhooks are built in. Matrix is not | Not documented Neither documented. A generic GET or POST action is | Not documented Neither documented. An HTTP action is | Not documented Neither documented | Partly Available as community packages only |
| Built for the modern estate | ||||||
| Proxmox guests in backup, migration or snapshot read as expected | Yes Every guest is its own value with its own rule, and those states are recognised as normal | Partly The official template reports guest status and migration. Backup and snapshot locks are not documented | Not documented Proxmox VE is supported. Guest lock handling is not documented | Partly Official sensors read a stopped guest as Warning. No lock channel is documented | Partly The XI wizard checks backup status. Guests are pinged as separate hosts | Partly Compares VM status to a set value, with a separate backup status check |
| MIBs loaded as data, with units and value names | Yes Pick an object by name. Type, unit, scaling and enumerations fill themselves in | Partly MIBs on the server translate names to OIDs, with a restart after any change | Partly Units and enumerations in Universal Device Poller. New MIBs are added by the vendor on request | Yes MIB Importer carries names and value lookups into the SNMP Library sensor | Partly MIBs can be uploaded, chiefly for trap handling | Not documented Around 1,000 coded SNMP check plug-ins. Loading your own MIBs is not documented |
| On the host | ||||||
| The agent cannot run commands or scripts | Yes No exec, no plug-ins, no custom checks and no write endpoint, and none will be added | No UserParameter runs any command the config names. system.run is denied by default | No The Linux/Unix Script Monitor runs custom scripts on the host | No The SSH Script sensor runs any executable placed in /var/prtg/scripts | No NRPE commands and NCPA plug-ins run any configured script | No Agent plug-ins, local checks and MRPE run custom executables on the host |
| The agent runs without root | Yes Its own unprivileged user, with no capability beyond binding a port | Yes Switches to user zabbix by default | Yes Runs as the unprivileged SWIAgent account | Not documented No Linux host agent. SSH sensors run as whichever account is configured | Yes NRPE refuses to run as root. NCPA runs as nagios by default | Partly Runs as root by default. Unprivileged only in the commercial editions |
| The host is judged on the host, and a verdict served | Yes Red or amber with the reason in words, from checks that remember what the host was doing | No The agent returns values. The server evaluates triggers against them | Partly A script's exit code sets status. Other thresholds are evaluated in SAM | Partly A script's exit code sets status. Other sensors send values for PRTG limits | Yes Plug-ins apply their warning and critical thresholds locally and return a status | Partly Local checks and MRPE can return a state. Standard agent output is judged by the server |
| Email delivery | ||||||
| A real message is sent and confirmed as arrived | Yes A round trip back to GEN, or one way to a delivery receipt or a bounce | Not documented The official SMTP template checks the TCP port only | Yes SAM templates round trip through IMAP4, POP3 or Exchange Web Services | Yes SMTP&IMAP and SMTP&POP3 Round Trip sensors | Yes The XI Email Delivery wizard. Core relies on a community plug-in | Yes The Check Email Delivery rule, check_mail_loop, run by the Checkmk server |
| One test proves mail both reaches you and leaves you | Yes In from the internet through your MX, then back out through your own route to GEN | Not documented | Partly One direction: through a named SMTP server into a mailbox it logs into | Partly One direction: through an SMTP server parent device into a mailbox it logs into | Partly One direction: through the SMTP details given into an IMAP mailbox | Partly One direction: sent by SMTP, EWS or Graph into a mailbox it logs into |
| No login to the customer's mail at all | Yes Nothing signs in anywhere. A round trip needs only a forwarding rule, one way nothing | Not documented | No Needs mailbox credentials and a named SMTP server | No Needs an IMAP or POP3 login, with an SMTP server as parent device | No Needs SMTP and IMAP details. IMAP reads the test back and deletes it | No Needs a mailbox login, and SMTP, EWS or Graph to send |
| Tests are held, not failed, when the monitor's own mail breaks | Yes GEN tests its own mailbox every minute. If it stops, tests show no data and staff are alerted | Not documented General trigger dependencies can hold back notifications | Partly A dependency set up by hand marks children Unreachable. Not specific to email | Partly A dependency set up by hand pauses sensors while their master is Down | Partly Service dependencies set up by hand suppress checks and notifications | Not documented Only host parents are documented |
| Behaviour over time | ||||||
| Behaviour analysis is switched on per check, not across everything | Yes One setting per sensor, off by default. Nothing else is analysed, or kept for analysis | Yes Anomaly functions act only where written into a trigger expression | Yes Dynamic baseline thresholds are chosen per node, interface or SAM template | No Unusual detection is on by default for every sensor, and can be switched off per probe, group or device | Yes XI Capacity Planning is set up per chosen service. Core has nothing built in | Yes Predictive levels are chosen per rule, on supported checks, in the commercial editions |
| A finding is its own state, not a warning or an alarm | Yes ABNORMAL for a trend, UNUSUAL for an odd day. Both count as working and notify nobody by default | No A finding raises an ordinary problem, at a severity from Information to Disaster | No Baseline breaches are ordinary Warning and Critical thresholds | Partly Its own orange Unusual status, but shown on the Alarms tab and able to trigger notifications | No A projected breach in XI raises an ordinary alert | No A deviation sets the service to ordinary WARN or CRIT |
| The threshold is measured from each sensor's own history, per time scale | Yes Per sensor, per probe and per time scale, by several measures that must agree. No multiple to choose | Partly Deviations from the item's own seasonal history, against a multiple the user sets | Partly The mean plus 2 or 3 standard deviations over the last seven days. No time-of-day split documented | Partly A ratio band, set system-wide, around the sensor's own hour-of-day and weekday averages | No XI alerts at a value the user sets | Partly Predicted from its own history per chosen period. The margin is set by the user, as a value, percentage or standard deviations |
| A slow drift is caught across days, weeks and months together | Yes Day, week, month, day of week and week of year, each against its own history, and they must agree in direction | Partly forecast and timeleft extrapolate a trend. Several time scales only by combining functions by hand | Partly Capacity forecasting projects daily trends from up to 180 days, shown in widgets | No Hourly and 24-hour averages only. No drift over weeks documented | Partly XI projects one trend over a set number of weeks, once a day | Partly A filesystem trend, and forecast graphs for viewing only. Predictive levels compare one period |
| Reports on trends and behaviour | ||||||
| Reports sent on a schedule | Yes Daily, weekly or monthly on local time, through the same delivery queue and retries as alarms | Partly A dashboard as PDF, daily to yearly, by email only | Yes Report schedules email, print or save a report to disk | Yes Hourly to quarterly, as PDF, HTML, CSV or XML, by email | Partly XI Enterprise emails any report daily, weekly or monthly. Core reports are on demand only | Partly PDF by email or stored, in the commercial editions only |
| The statistics are worked out for you | Yes Average, median, 95th percentile, spread, trend, busiest hours and days, gaps and availability | Not documented Whatever the dashboard's widgets show. No statistics block documented | Yes 95th percentile and trend lines on report charts | Partly Averages, and percentile tables per channel. No trend documented | Partly Minimum, average and maximum on graphs. Trend in the capacity planning report | Partly Minimum, maximum and average. No percentile documented |
| Each figure is compared with the period before | Yes The previous day, week or month, and it says so when there is nothing to compare with | Not documented | Not documented | Not documented A report can cover the period just ended. Comparison with the one before is not documented | Not documented | Not documented |
| A written account of what the data shows, drawn up by AI | Yes The typical level, the pattern, peaks, trend, anything unusual and whether anything needs doing | Not documented Statistical anomaly and forecast functions for triggers. No written report | Not documented Capacity forecasting and anomaly-based alerting. No AI in reports documented | Not documented Machine-learnt anomaly detection in the interface. No AI in reports documented | Not documented Capacity planning adds a written summary of its forecast. Not described as AI | Not documented Forecast graphs can go in a report. No AI in reports documented |
| Getting at the data | ||||||
| An API for state, readings and history | Yes Six read-only endpoints: tree, state, readings, state changes, availability and charts | Yes JSON-RPC API, read and write, for history, events and problems | Yes SWIS over REST or SOAP, with SWQL queries, read and write | Yes HTTP API reads and changes objects. API v2 is not yet feature-complete | Yes XI REST API, with writes for administrators only. Core JSON CGIs read | Yes REST API, read and write. Livestatus for status and history |
| Availability figures from the API | Yes Worked out as the dashboard does, with no data kept apart from downtime | Yes sla.getsli returns uptime, downtime and error budget per period | Partly No SLA method. Availability can be averaged in a SWQL query | Partly Cumulative uptime and downtime. Figures for a period are in reports | Yes Core's archive JSON CGI has an availability query. Not documented for XI | Yes Livestatus state history gives availability, unmonitored time included |
| Charts as images from the API | Yes The image the dashboard exports, sized and themed per call | Not documented | Not documented | Yes chart.png and chart.svg, served beside the API | Not documented | Not documented Metric endpoints return data, not images |
| A key limited to part of the estate and to named addresses | Yes One key per integration, to a branch and to IPv4 or IPv6 addresses or ranges | Partly A token inherits its user's host group permissions. Address limits not documented | Partly Uses an account and its account limitations. Address limits not documented | Partly Keys per user, from read only to full access. Address limits not documented | Partly One key per XI user. Address limits not documented | Partly Automation users carry their own permissions. Only the Livestatus port is limited by address |
| A phone view that does not start with signing in again | Yes A separate view-only page, paired once from the desktop and then held behind a four digit PIN. No app to install, and nothing on it can change the estate | Partly The ordinary frontend, with a Remember for 30 days option on sign in. The vendor app is announced but not released, and no phone view is documented | Partly A mobile view of the web console, documented in one support article last reviewed in 2022. Mobile Admin reached end of life in 2021, and the console times out after 25 minutes idle | Yes Current iOS and Android apps that hold the account signed in, with push notifications. The mobile web interface was removed in 2016 | Partly XI has a documented mobile interface, and two-factor can be remembered per browser, though the password cannot. Core relies on community front ends | Partly A separate mobile interface is in the product but absent from the user guide, and a session idles out after ninety minutes |
| CSV as well as JSON | Yes Every endpoint, with paging fields sent as headers | Not documented Requests and responses are JSON | Not documented REST responses are JSON | Yes CSV tables, and historic data as CSV | Not documented XI returns XML or JSON | Partly The REST API is JSON. Livestatus and availability views give CSV |
| Running it | ||||||
| What you have to host | Nothing. GEN runs the service end to end | A Linux server, database and proxies, or Zabbix Cloud | Windows Server with Microsoft SQL Server and polling engines. SaaS is a separate product | A Windows core server and probes, or PRTG Hosted Monitor | A Linux server. No vendor-hosted edition documented | A Linux server, appliance or Docker, or Checkmk Cloud |
| How it is charged | Per read, from £0.00002, invoiced monthly in arrears | Free software (AGPLv3) with optional support. Cloud by values-per-second tier | Node-based subscription on multi-year contracts, billed annually | Subscription in sensor-count tiers. Freeware up to 100 sensors | Core is free. XI is licensed per node, with annual maintenance | Per service, by annual subscription. Community edition is free |
No way in, and no server of yours to patch.
- Outbound HTTPS only. Nothing connects to a probe.
- Signed on every request. Each probe generates its own ed25519 key at enrolment. GEN holds only the public half.
- A pinned uplink. TLS 1.3, always verified, on a client kept apart from the one that reaches your kit.
- Updates that cannot brick. Length, hash and a test start are checked before a new build replaces anything.
No nodes to count, no tiers to cross.
Per read, from £0.00002, invoiced monthly in arrears. Rules, schedules, templates, escalation and delivery history are included, and a probe group that is down costs nothing.
| A ping every minute from one location |
£0.86 a month |
| A Proxmox guest sensor HTTPS with a user function, from three locations every minute |
£20.74 a month |
| A website check HTTPS from twenty locations every minute |
£69.12 a month |
Indicative, based on a 30-day month. Work out your own estate.
Monitoring you can believe at three in the morning.
Oversight is a managed service from GEN, running across four live sites ahead of general release.
Sources for Zabbix 31
- https://www.zabbix.com/license
- https://www.zabbix.com/cloud
- https://www.zabbix.com/documentation/8.0/en/manual/installation/requirements
- https://www.zabbix.com/documentation/7.0/en/manual/distributed_monitoring/proxies/ha
- https://www.zabbix.com/documentation/current/en/manual/config/triggers/dependencies
- https://www.zabbix.com/documentation/8.0/en/manual/config/triggers/expression
- https://www.zabbix.com/documentation/8.0/en/manual/config/notifications/media/webhook
- https://www.zabbix.com/documentation/current/en/manual/config/items/itemtypes/snmp/mibs
- https://github.com/zabbix/zabbix/blob/master/templates/app/proxmox/README.md
- https://www.zabbix.com/integrations/ceph
- https://www.zabbix.com/integrations/smtp
- https://www.zabbix.com/documentation/current/en/manual/api
- https://www.zabbix.com/documentation/current/en/manual/api/reference/sla/getsli
- https://www.zabbix.com/documentation/current/en/manual/api/reference/history/get
- https://www.zabbix.com/documentation/current/en/manual/web_interface/frontend_sections/users/api_tokens
- https://www.zabbix.com/documentation/current/en/manual/config/reports
- https://www.zabbix.com/documentation/current/en/manual/appendix/functions/trends
- https://www.zabbix.com/documentation/current/en/manual/config/triggers/prediction
- https://www.zabbix.com/documentation/8.0/en/manual/whatsnew
- https://www.zabbix.com/roadmap
- https://blog.zabbix.com/creating-a-personal-assistant-in-zabbix-with-artificial-intelligence/29596/
- https://blog.zabbix.com/when-generative-ai-meets-zabbix/30908/
- https://www.zabbix.com/documentation/current/en/manual/config/items/userparameters
- https://www.zabbix.com/documentation/current/en/manual/appendix/config/zabbix_agentd
- https://www.zabbix.com/documentation/current/en/manual/appendix/install/run_agent_as_root
- https://www.zabbix.com/documentation/current/en/manual/config/triggers
- https://www.zabbix.com/mobile_app
- https://www.zabbix.com/documentation/current/en/manual/quickstart/login
- https://www.zabbix.com/documentation/current/en/manual/appendix/functions/prediction
- https://www.zabbix.com/documentation/current/en/manual/config/triggers/severity
- https://www.zabbix.com/documentation/6.0/en/manual/introduction/whatsnew600
Sources for SolarWinds 34
- https://documentation.solarwinds.com/en/success_center/orionplatform/content/orion_platform_licensing_model.htm
- https://documentation.solarwinds.com/en/success_center/orionplatform/content/system_requirements/solarwinds_platform_2026-2_system_requirements.htm
- https://documentation.solarwinds.com/en/success_center/orionplatform/content/core-changing-polling-engine-node-assignments-sw236.htm
- https://documentation.solarwinds.com/en/success_center/orionplatform/content/core-creating-a-new-dependency-sw1316.htm
- https://documentation.solarwinds.com/en/success_center/orionplatform/content/core-calculating-node-availability-sw1184.htm
- https://documentation.solarwinds.com/en/success_center/orionplatform/content/core-using-get-or-post-url-functions-sw1058.htm
- https://documentation.solarwinds.com/en/success_center/orionplatform/content/core-creating-universal-device-pollers-sw551.htm
- https://support.solarwinds.com/SuccessCenter/s/article/Upload-MIB-in-Orion-Universal-Device-Poller
- https://documentation.solarwinds.com/en/success_center/orionplatform/content/release_notes/hco_2026-2_release_notes.htm
- https://documentation.solarwinds.com/en/success_center/sam/content/sam-imap4-round-trip-email-sw4938.htm
- https://documentation.solarwinds.com/en/success_center/sam/content/sam-imap4-user-experience-monitor-sw3251.htm
- https://documentation.solarwinds.com/en/success_center/sam/content/sam-pop3-user-experience-monitor-sw3284.htm
- https://documentation.solarwinds.com/en/success_center/sam/content/sam-exchange-web-services-user-experience-monitor-sw3215.htm
- https://solarwinds.github.io/OrionSDK/docs/about-swis/
- https://solarwinds.github.io/OrionSDK/docs/rest/
- https://documentation.solarwinds.com/en/success_center/orionplatform/content/core-setting-account-limitations-sw2027.htm
- https://support.solarwinds.com/SuccessCenter/s/article/Understanding-the-Custom-SLA-Report-SWQL-query
- https://documentation.solarwinds.com/en/success_center/orionplatform/content/release_notes/hco_2026-1_release_notes.htm
- https://documentation.solarwinds.com/en/success_center/orionplatform/content/swo/core-sw1-faqs.htm
- https://documentation.solarwinds.com/en/success_center/orionplatform/content/core-scheduling-reports-sw2009.htm
- https://documentation.solarwinds.com/en/success_center/orionplatform/content/core-creating-assigning-and-editing-new-report-schedules-in-report-manager.htm
- https://documentation.solarwinds.com/en/success_center/orionplatform/content/core-add-custom-chart-to-report.htm
- https://documentation.solarwinds.com/en/success_center/orionplatform/content/core-customizing-charts-in-the-orion-web-console-sw1349.htm
- https://documentation.solarwinds.com/en/success_center/orionplatform/content/swo/hco_anomaly-based-alerting.htm
- https://documentation.solarwinds.com/en/success_center/npm/content/npm-capacity-forecasting-sw1526.htm
- https://documentation.solarwinds.com/en/success_center/sam/content/sam-linux-unix-script-monitor-sw3260.htm
- https://documentation.solarwinds.com/en/success_center/orionplatform/content/core-linux-agent-credential-privileges.htm
- https://support.solarwinds.com/SuccessCenter/s/article/Access-the-mobile-view-of-the-Orion-Web-Console
- https://support.solarwinds.com/SuccessCenter/s/article/Currently-supported-software-versions
- https://documentation.solarwinds.com/en/success_center/orionplatform/content/core-orion-baseline-data-calculation.htm
- https://documentation.solarwinds.com/en/success_center/orionplatform/content/core-orion-thresholds-sw1775.htm
- https://documentation.solarwinds.com/en/success_center/sam/content/sam-automatic-calculation-of-baseline-data-sw1047.htm
- https://documentation.solarwinds.com/en/success_center/orionplatform/content/core-setting-trigger-conditions-sw1034.htm
- https://documentation.solarwinds.com/en/success_center/npm/content/npm-forecasting-capacity-for-nodes-or-interfaces-sw1530.htm
Sources for PRTG 33
- https://www.paessler.com/pricing
- https://www.paessler.com/prtg/system-requirements
- https://www.paessler.com/prtg/prtg-hosted-monitor
- https://www.paessler.com/manuals/prtg/failover_cluster
- https://www.paessler.com/manuals/prtg/sensor_states
- https://www.paessler.com/manuals/prtg/dependencies
- https://www.paessler.com/manuals/prtg/notification_templates
- https://www.paessler.com/manuals/prtg/historic_data_reports
- https://www.paessler.com/manuals/prtg/proxmox_ve_virtual_machine_status_sensor
- https://www.paessler.com/manuals/prtg/proxmox_ve_cluster_health_sensor
- https://www.paessler.com/tools/mibimporter
- https://www.paessler.com/manuals/prtg/smtp_imap_round_trip_sensor
- https://www.paessler.com/manuals/prtg/smtp_pop3_round_trip_sensor
- https://www.paessler.com/manuals/prtg/http_api
- https://www.paessler.com/manuals/prtg/historic_data
- https://www.paessler.com/manuals/prtg/live_graphs
- https://www.paessler.com/manuals/prtg/live_data
- https://www.paessler.com/manuals/prtg/api_keys
- https://www.paessler.com/support/prtg/api/v2/overview/index.html
- https://www.paessler.com/prtg/history/stable
- https://www.paessler.com/manuals/prtg/reports
- https://www.paessler.com/manuals/prtg/report_settings
- https://www.paessler.com/prtg/features/ai-in-prtg
- https://www.paessler.com/manuals/prtg/similar_sensors
- https://www.paessler.com/manuals/prtg/ssh_script_sensor
- https://www.paessler.com/manuals/prtg/device_settings
- https://www.paessler.com/manuals/prtg/custom_sensors
- https://www.paessler.com/manuals/prtg/prtg_apps_for_mobile_network_monitoring
- https://helpdesk.paessler.com/en/support/solutions/articles/76000067807-why-does-paessler-remove-the-mobile-web-gui-from-prtg-
- https://www.paessler.com/manuals/prtg/monitoring
- https://www.paessler.com/manuals/prtg/alarms
- https://www.paessler.com/manuals/prtg/notification_triggers_settings
- https://blog.paessler.com/paessler-prtgs-predictive-and-proactive-ai-features
Sources for Nagios 28
- https://www.nagios.com/pricing-plans/
- https://library.nagios.com/docs/nagios-xi/configuration/Nagios-XI-System-Requirements
- https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/networkreachability.html
- https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/freshness.html
- https://assets.nagios.com/downloads/nagiosxi/docs/Monitoring-Proxmox-with-Nagios-XI.pdf
- https://support.nagios.com/kb/article/nagios-xi-uploading-and-managing-mibs-852.html
- https://assets.nagios.com/downloads/nagiosxi/docs/Monitoring-Email-Delivery-with-Nagios-XI.pdf
- https://exchange.nagios.org/directory/plugins/email-and-groupware/check_email_delivery/details/
- https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/dependencies.html
- https://library.nagios.com/docs/nagios-xi/configuration/Nagios-XI-REST-API
- https://assets.nagios.com/downloads/nagiosxi/docs/Accessing-and-Using-the-XI-REST-API.pdf
- https://github.com/NagiosEnterprises/nagioscore/blob/master/html/jsonquery.html
- https://www.nagios.com/changelog/nagios-xi/
- https://assets.nagios.com/downloads/nagiosxi/guides/administrator/monitoringconfig.php
- https://assets.nagios.com/downloads/nagiosxi/docs/Scheduled-Reports.pdf
- https://assets.nagios.com/downloads/nagiosxi/docs/How_To_Use_Capacity_Planning.pdf
- https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/cgis.html
- https://github.com/NagiosEnterprises/nrpe/blob/master/SECURITY.md
- https://github.com/NagiosEnterprises/nrpe/blob/master/sample-config/nrpe.cfg.in
- https://www.nagios.org/ncpa/help/3.x/configuration.html
- https://www.nagios.org/ncpa/help/3.x/api.html
- https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/pluginapi.html
- https://library.nagios.com/docs/nagios-xi/configuration/Nagios-XI-Mobile-User-Interface
- https://library.nagios.com/docs/nagios-xi/configuration/Nagios-XI-Two-Factor-Authentication
- https://assets.nagios.com/downloads/nagiosxi/docs/Using-Capacity-Planning-in-Nagios-XI-2024.pdf
- https://library.nagios.com/nagios-updates/whats-new-in-nagios-xi-2026/
- https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/plugins.html
- https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/statetypes.html
Sources for Checkmk 31
- https://checkmk.com/pricing
- https://checkmk.com/werk/19391
- https://docs.checkmk.com/latest/en/install_packages.html
- https://docs.checkmk.com/latest/en/distributed_monitoring.html
- https://docs.checkmk.com/latest/en/monitoring_basics.html
- https://docs.checkmk.com/latest/en/notification_rules.html
- https://docs.checkmk.com/latest/en/availability.html
- https://docs.checkmk.com/latest/en/agent_linux.html
- https://docs.checkmk.com/latest/en/wato_monitoringagents.html
- https://docs.checkmk.com/latest/en/localchecks.html
- https://docs.checkmk.com/latest/en/agent_single_folder.html
- https://docs.checkmk.com/latest/en/snmp.html
- https://checkmk.com/integrations/proxmox_ve_vm_info
- https://checkmk.com/integrations/proxmox_ve_vm_backup_status
- https://exchange.checkmk.com/p/checkmk-matrix-notify
- https://exchange.checkmk.com/p/rocketchat-notification
- https://checkmk.com/integrations/check_mail_loop
- https://checkmk.atlassian.net/wiki/spaces/KB/pages/9472304/Configuring+Check+Email+Delivery+check_mail_loop
- https://docs.checkmk.com/latest/en/active_checks.html
- https://docs.checkmk.com/latest/en/rest_api.html
- https://docs.checkmk.com/latest/en/livestatus.html
- https://docs.checkmk.com/latest/en/wato_user.html
- https://checkmk.com/product/release-notes/2-5-0
- https://checkmk.com/blog/key-highlights-checkmk-25
- https://docs.checkmk.com/latest/en/reporting.html
- https://docs.checkmk.com/latest/en/graphing.html
- https://docs.checkmk.com/latest/en/forecast_graphs.html
- https://checkmk.com/werk/10452
- https://checkmk.com/werk/12061
- https://docs.checkmk.com/latest/en/predictive_monitoring.html
- https://checkmk.com/integrations/df
Comparison drawn from each vendor's published documentation, checked on 16, 17, 19, 21, 22 and 23 September 2026. Zabbix, SolarWinds, PRTG, Nagios and Checkmk are trademarks of their respective owners, who are not affiliated with GEN and have not endorsed this comparison. If anything here has fallen out of date, tell us and we shall correct it.