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, 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.
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.
Oversight against the established monitors.
Every entry for another product is taken from that vendor's own documentation, checked on 16 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 |
| 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 |
| 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 10
- 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
Sources for SolarWinds 9
- 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
Sources for PRTG 11
- 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
Sources for Nagios 6
- 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
Sources for Checkmk 14
- 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/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
Comparison drawn from each vendor's published documentation, checked on 16 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.