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.
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.
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 and 17 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 |
| 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 |
| 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 |
| 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 15
- 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
Sources for SolarWinds 17
- 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
Sources for PRTG 19
- 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
Sources for Nagios 12
- 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
Sources for Checkmk 20
- 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
- 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
Comparison drawn from each vendor's published documentation, checked on 16 and 17 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.