Oversight compared with Zabbix, SolarWinds, PRTG, Nagios, Checkmk, LogicMonitor and OpManager

The architecture

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.

The traditional model

The Oversight model

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.

Nested and cascaded conditions

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.

Deterministic actions

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.

EmailHTML over your own SMTP relay, charts inline and the poll log attached

SMSA length-checked summary that still says what is down

MatrixMarkdown, straight to your homeserver

XMPPInto the rooms and clients your team already uses

Rocket.ChatMarkdown, into the channel that owns the kit

REST and webhooksA whole HTTP request as a template, so anything with an API

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.
Nobody acknowledges, and the alarm climbs: to a second team, to everyone, or to a call that runs a recovery script or starts an n8n flow.
One acknowledgement stops the whole alarm at every tier, however many objects it holds. Nobody acknowledges a rack outage sensor by sensor.
A system taking alarms by webhook reads and acknowledges them through the API, so a playbook already dealing with it stops the climb.
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.

POSTn8n flow · 1 call, 3 objects

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"}
 ]}

Sensors

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.

Email round trip, in and back out, or one way Linux and Windows agents, read only Windows event log as syslog, from the agent Syslog, log files and the journal, filtered on site SSH RDP, including NLA enforcement SNMP v1, v2c and v3 with MIBs HTTP(S), REST and SOAP SMTP IMAP4 DNS SIP OPTIONS MySQL and MariaDB MongoDB FTP and FTPS, with file age TCP Ping

Email, end to end

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.

The usual round trip

The Oversight round trip

The Linux and Windows agents

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.

The usual agent

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, and OpManager's Linux agent installs as root unless told not to.

The Oversight agent

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.
The event log, as syslog. The Windows agent forwards the logs you choose to Oversight's syslog sender or any syslog server, with no third-party forwarder. Off unless set on the server itself.

Statistical behaviour analysis

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 PRTG and OpManager do 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.

The usual anomaly band

The Oversight ladder

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.

Explained in plain English

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.

CRITHead Office · BT-001

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 nearly always 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. PRTG passes alarms through a Paessler gateway to Anthropic's Claude. LogicMonitor's Edwin AI uses OpenAI models through Microsoft Azure, where data may be kept for up to 30 days. OpManager is the exception: it can be pointed at a model you host yourself, and otherwise uses a public provider on your own key.

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.

Built to run at scale

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.

Feature by feature

Oversight against the established monitors.

Every entry for another product is taken from that vendor's own documentation, checked on 2 October 2026. Hover over or tap a mark for the detail behind it.

	Oversight	Zabbix	SolarWinds	PRTG	Nagios	Checkmk	LogicMonitor	OpManager
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	Yes Hosts are assigned to a proxy group, not a proxy. The group shares them out and moves a failed proxy's hosts to the others	Partly Each node is polled by one polling engine at a time. HA pools add standby failover and, since 2026.2, automatic load balancing between engines	Partly A sensor belongs to one probe. Only a failover cluster monitors from every node	Yes Mod-Gearman workers that serve the same hostgroup queue share its checks and take over from one another. Managed in the XI interface from 2024R2.1	Partly Each host is monitored by one site or Relay. A site on two Checkmk appliances can fail over to the standby node	Yes Auto-balanced collector groups share out resources and move a dead collector's share to the rest. One collector polls a resource at a time	Partly Each device is monitored by the one probe for its network. Failover gives a server or probe a hot standby, not a peer
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 at a time. HA pools fail over and balance load, they do not vote	Partly A failover cluster shows Down (Partial) when nodes disagree. No quorum setting, and not for remote probes	No No vote is built in. The same check run from several workers can be combined by hand with check_cluster or a BPI group threshold	No Each host is monitored by exactly one site. An appliance cluster is standby failover, not voting	Partly LM Uptime web and ping checks raise an overall alert when all, half, more than one or any locations fail. Other monitoring uses one collector per resource	No Each device is polled by one probe. Failover is active and standby, not voting
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	No Triggers can go Unknown, but a service has no such status. SLA time is counted only as uptime or downtime	No A ping with no reply is recorded as Down, even when the fault is on the poller's side of the path. Only unmanaged or maintenance time is left out of availability	Yes Unknown time counts as neither uptime nor downtime, and data tables show coverage. The separate SLA Reporter counts Unknown after a Down as downtime by default	Partly Availability reports keep Undetermined time and UNKNOWN apart from down time. By default a monitoring outage assumes the last state, and an orphaned Mod-Gearman check reports CRITICAL	Partly Unmonitored time has its own N/A column and UNKNOWN its own state, both by default. A service with no fresh data keeps its last state, marked stale	Partly Configurable per SLA widget or report: no data can be left out, counted as down or counted as up. No default is documented	Partly Not Monitored time is never counted as downtime, but it is counted as available. It is shown separately in reports and on the availability timeline
A corrected rule can be re-applied to past readings	Yes Raw readings are kept exactly and history is re-evaluated against the fix	No Triggers are evaluated as values arrive. Changing one does not re-evaluate past readings	No Statuses and alerts stay as they were recorded. After seven days, by default, readings are rolled up to hourly and then daily averages	No Limits set the status as each reading arrives. Past states are not re-evaluated, though the separate SLA Reporter lets past outages be marked as planned by hand	No Each plug-in judges a reading against its thresholds when it is taken, and only the resulting state is logged for reports. Re-evaluating history is not documented	Partly Annotations can set a new state or reclassify downtime for a past period, by hand. Thresholds are not re-applied to past readings	No Alerts are raised as readings arrive. Re-applying a changed threshold to stored history is not documented	No Thresholds apply to new polls only. Re-applying them to stored history 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. A service action can send one message listing every problem behind a service	Yes Aggregate alerts, an advanced option, combine every object that meets a rule into one alert. Dependencies and suppression conditions hold back the knock-on alerts	Partly Templates can summarise events into one message of up to 1,000 characters, except for Slack, Teams, HTTP, program and ticket actions	Partly Parent hosts mark children UNREACHABLE, which can be left unnotified	Yes Bulk notifications collect problems into one message per contact, grouped by host or other fields, up to a set count	Partly Dependent Alert Mapping holds back notifications for dependent alerts, in the Enterprise edition. Edwin AI, an add-on, groups alerts into one ServiceNow incident	Yes Event Correlation groups related alerts into one Problem and notifies on the Problem, naming the devices affected. Uplink dependencies also hold back alarms from devices behind a failed parent. Not in Standard
The message shows cause and consequence as a tree, worst first	Yes Site, group, device and the check beneath it that took it there	Partly A service action can list the problems that failed a service, worst first. A flat list under one service, not a tree	No Each alert message describes its own object. A cause and consequence tree in the message is not documented	No A summary lists the triggered sensors. Each sensor's probe, group and device are available as placeholders, with no tree or ordering by severity	No Each notification covers one host or service, built from macros. Parent and child hosts are not shown together in a message	Partly A BI aggregation made into a service lists its failing branches as a tree, which the email carries. Built by hand, and not ordered worst first	Partly Notifications can carry the originating cause, the direct cause and a count of dependent alerts. Not as a tree, and in the Enterprise edition only	No A Problem notification lists the affected devices, not a tree
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	No None built in. Community add-ons on the Zabbix blog send a problem to Gemini	Partly SW1, an AI agent in technical preview, answers questions about alerts in a side panel. Not in the message	Partly Alarm Insights, in early access in the new interface, explains active alarms in plain English with suggested fixes. Not in the message	No No AI summary in notifications. An experimental XI helper, added in 2026R1.2, adds and removes hosts from a typed request	Partly Explain with AI explains a service in the interface, in Checkmk Cloud only. Not in the message	Partly Edwin AI, an add-on, writes an AI summary of an incident in its own interface and can use it as the ServiceNow incident description. Alert emails and chat messages carrying it are not documented	Partly A connected model summarises an alarm, all alarms or a correlated Problem on request in the interface. Not in the notification
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	NA No AI feature of its own. The community add-ons on its blog send problems to Google's Gemini	No Requests go through Platform Connect to SolarWinds' cloud and on to commercial model providers. Prompts, outputs and logs are retained	No Alarm Insights sends alarms through a Paessler gateway to Anthropic's Claude. Prompt logging is not documented	NA No AI writes messages or reports. The experimental XI helper uses a small classifier that runs on the customer's own XI server	No Explain with AI sends host and service data to an external AI provider. Prompt logging by that provider is not documented	No Edwin AI uses OpenAI models through Microsoft Azure, and Amazon Bedrock. Data may be kept in Azure for up to 30 days for abuse monitoring	Partly With a local Ollama model nothing leaves the customer's network. The other choices send prompts to OpenAI, Azure OpenAI, Anthropic or Google Gemini on the customer's own key
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 only as a community webhook	No Neither is built in. A generic GET or POST action can call a webhook	No Neither is built in. Rocket.Chat can be reached by hand through an Execute HTTP Action	No Neither is built in. XI ships Slack and Discord notification wizards, and any script can be set as a notification command	Partly Neither is built in. Both are available as community packages on Checkmk Exchange	No Slack and Microsoft Teams are built in, Matrix and Rocket.Chat are not. Custom HTTP delivery posts to any web address	No Neither. Slack and Microsoft Teams are built in, with Google Chat, Telegram, Webex, WhatsApp and others through a generic webhook
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. It does not read backup or snapshot locks	No VMAN monitors Proxmox VE 8 hosts and guests, with disk and snapshot details. Backup, migration and snapshot locks are not documented	Partly Official sensors read a stopped guest or container as Warning. No lock channel is documented	Partly The XI 2026 wizard reads each guest as running or stopped, and checks it is covered by a backup job. Backup, migration and snapshot locks are not read	Yes Each guest has a VM Info service that shows a backup, migrate or snapshot lock as OK. It warns only if the lock lasts past set levels, 15 and 30 minutes by default	No No Proxmox modules from LogicMonitor. Proxmox support is an open feature request on the vendor's community site	Partly Clusters, nodes, VMs and containers are discovered through the Proxmox API. Backup, migration and snapshot locks are not documented
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 Universal Device Poller picks objects from a MIB database the vendor maintains, with units and value names set by hand in each poller. New MIBs are added by the vendor on request	Yes MIB Importer carries names and value lookups into the SNMP Library sensor	Partly Uploaded MIBs name the objects in the SNMP Walk wizard and add trap definitions. Units and thresholds are entered by hand	Partly MIBs can be uploaded for trap translation in the Event Console. Polling uses around 1,000 coded SNMP check plug-ins	Partly Uploaded MIBs translate SNMP traps. SNMP DataSources take each OID by hand	Partly MIBs can be uploaded and objects picked from the tree. The unit and any value lookups are typed in by hand on each custom monitor
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, under the agent's own account if no other credential is given	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	No The Collector runs embedded Groovy and PowerShell, and any external script or program. RemediationSources run scripts against monitored hosts	No Script monitors are pushed from the server and run by the agent 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 The Linux agent runs as its own SWIAgent service account, which cannot log in. Root is needed only to install it	NA No host agent. SSH sensors run as the account configured, optionally through sudo	Yes NRPE refuses to run as root. NCPA runs as nagios by default	Partly The agent script runs as root by default. A fully unprivileged agent package needs a commercial edition	Yes The Linux installer creates and runs as the unprivileged user logicmonitor, with sudo rules for restarts. Windows can run as a restricted account or Local System	Partly The Linux agent installs as root unless the non-root option is given. The Windows agent's service account is not documented
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	Partly A script can work out a status and return it as a value. Thresholds on every value are applied by the LogicMonitor platform	Partly A script's exit code marks it up or down. Other readings are sent to the server and judged against thresholds set in OpManager
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	No The official SMTP template checks the TCP port only. No message is sent	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	Yes Email_RoundTrip sends by SMTP and reads the message back by IMAP. Email_TransitTime sends from one mail provider to another	Yes The Mail Server monitor in the bundled Applications Manager plug-in sends a test mail by SMTP and fetches it back by POP or IMAP
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	NA There is no email delivery test	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	Partly Email_TransitTime tests one direction per instance, so two instances cover both. Each relies on logins at both providers	Partly One direction: through the named SMTP server 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	NA There is no email delivery test. The SMTP port check needs no login	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 to read the test back, and SMTP, EWS or Graph to send	No Needs SMTP and IMAP logins, or OAuth app credentials, for every mailbox used	No Needs a POP or IMAP login, and SMTP details with optional authentication
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	NA There is no email delivery test. General trigger dependencies can hold back notifications	Partly A dependency set up by hand marks children Unreachable, and a suppression condition can mute their alerts. 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	No Only host parents are documented, and they hold back alerts for unreachable hosts, not for a failed service	No Nothing specific to mail tests. Dependent Alert Mapping works from network topology and reachability alerts only	Partly An uplink dependency set up by hand marks dependants Dependent Unavailable and holds their alarms. Not specific to email
Logs
Log lines are filtered where they are collected, and only the matches sent	Yes Rules at the site or on the host pick the lines out, the Windows event log included, forwarded by the agent. Everything else stays where it was written	Partly The agent's log[], logrt[] and eventlog[] items apply a regexp on the host and send only the matching lines. Syslog has no receiver: rsyslog must write it to a file for an agent to read	Partly Windows events are limited by a whitelist query, edited by hand in Global Advanced Configuration. Log file profiles take only a path, and Flag for discard drops entries after they arrive	Partly Devices stream all their syslog to a probe, which filters it and keeps the matches. Log files are read whole over SMB by the probe, and nothing reads the journal	Partly Agent checks (check_log, check_logfiles, NCPA event log filters) match on the host but return a status with a count or last line. Device syslog goes whole to the separate Log Server and is filtered there	Yes mk_logwatch matches patterns on the host and sends only matching lines with their state. The agent filters Windows event logs. Each site can run its own Event Console for syslog and traps	Yes LogSource include and exclude filters run on the collector for syslog and Windows event logs, and on the LM OTel Collector for log files. Only matching events are ingested	Partly The agent matches log file lines on the Windows host and sends only alarms. Syslog and event log rules run on the server, or on the probe at the site in Enterprise
A silence in the logs is shown as a gap, not taken for a quiet spell	Yes A stretch when nothing arrived is marked as a gap among the lines, by default, and GEN is told when a sender stops	Partly A log item sends nothing when no lines match, so a silence is not marked. A nodata() trigger must be added by hand. Active agent heartbeats show when the agent stops	No No alert for a log source that stops sending is documented. The default agent overload alert covers an agent that cannot keep up, not a source gone quiet	Partly Sensors on a stopped or cut-off probe show Unknown and Probe Health goes Down. A device that stops sending syslog leaves the sensor Up, as if nothing happened	Partly Only in the separately licensed Log Server, where a host freshness alert, set up by hand per host or subnet, fires when no logs arrive within an hour	Partly Logwatch services go stale when the agent stops sending data. For syslog and traps, an Event Console rule can be set by hand to expect regular messages and raise an event if none arrive	Partly Log anomaly detection flags stops in periodic log events but raises no alert. Log alerts fire only on matching incoming events. A Collector Down alert covers a dead collector	Partly Agent Down and Agent Not Communicating alarms show when a log file agent stops. Nothing flags a device that stops sending syslog, and quiet logs are not marked as gaps
Syslog and host logs are collected by the product itself, not a separate one	Yes A syslog sender for a site, fed the Windows event log by the agent, and a log sender for a host's files, journal or cron output. The agent also alarms on named events	Partly The agent reads host log files and Windows event logs. There is no syslog receiver: devices send to rsyslog, which writes a file. Syslog collection is on the roadmap for 8.2	Partly The free Log Viewer receives syslog and traps only. Log files and Windows events need Log Analyzer, a separate module or part of Observability Self-Hosted Essentials	Yes Syslog Receiver, Event Log and File Content sensors are all in the core product. Linux log files must be shared over SMB before the File Content sensor can read them	Partly XI reads host log files and Windows event logs through agent checks. Receiving syslog from devices needs Nagios Log Server, a separate product with its own licence	Yes The agent reads log files and Windows event logs, and the built-in Event Console receives syslog and SNMP traps, in all editions. Network syslog reception is switched on per site	Yes The collector receives syslog and reads Windows event logs, and the LM OTel Collector reads host log files. LM Logs is in every package, billed per GB ingested	Partly Syslog and Windows event logs are received in every edition. Text log files need the agent, which is Windows only and not in Standard. No separate product is needed
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 alerts are set up per chosen service, in the Enterprise edition. Core has nothing built in	Yes Predictive levels are chosen per rule, on supported checks, in the commercial editions	Yes Dynamic thresholds are added per datapoint, from a whole DataSource down to one instance. Anomaly bands can be drawn on any graph	No Anomaly detection is on by default for every device, with nothing to configure. Adaptive thresholds, by contrast, are chosen per monitor
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. Anomaly-based alerts are ordinary alerts	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	No A dynamic threshold breach raises an ordinary warning, error or critical alert	Partly Anomalies have their own list and dashboard, apart from alarms, but are graded Attention, Trouble or Critical. Adaptive threshold breaches raise ordinary alarms
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, with the multiple editable in SAM. 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 over one chosen period. The margin is set by the user, as a value, percentage or standard deviations	Partly Per datapoint instance, from up to 15 days of its own history with daily and weekly patterns. Severities and trigger criteria are set by the user	Partly An hourly forecast from each monitor's own history, learning daily, weekly and monthly cycles. The margin is set by the user, as a value or a percentage
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	Partly Forecasts project one trend from a chosen training range, on graphs and in the Alert Forecast report. No comparison across several time scales	Partly Forecasts project one trend from recent history to the date a resource reaches 80, 90 or 100 per cent. No comparison across weeks or months together
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 yearly, as PDF with optional CSV or XML data, by email or stored	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	Yes Daily, weekly or monthly, as HTML, PDF or CSV, by email. Any dashboard can be scheduled as a report	Yes Daily, weekly or monthly, as PDF or Excel, by email attachment or a published link. Not in Standard
The statistics are worked out for you	Yes Average, median, 95th percentile, spread, trend, busiest hours and days, gaps and availability	Partly Graphs can show a percentile line, and widgets aggregate by minimum, maximum, average, sum or count. No statistics block	Yes 95th percentile and trend lines on report charts	Partly Averages, minimum and maximum, and percentile tables per channel. No trend documented	Partly Last, maximum and average on performance graphs. A trend in the Enterprise capacity planning report	Partly Minimum, maximum and average over a chosen time range. No percentile documented	Partly Minimum, maximum, average, change and sum in the metric trends report. 95th percentile in the interface bandwidth report	Yes Minimum, maximum, average and 95th percentile on graphs and reports, with forecast trends in their own reports
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	Partly A graph can overlay the period before through a time-shifted copy of its data set. Set up by hand, graph by graph	No Reports and charts cover a chosen time range. Comparison with the period before is not documented	No A report can cover the period just ended. Comparison with the one before is not documented	No Reports cover one chosen period, such as last week or last month. Comparison with the period before is not documented	No Reports and availability cover one chosen time range. Comparison with the period before is not documented	Partly Graphs can overlay the signal from 24 hours, a week or 30 days earlier. No period comparison in reports is documented	Partly Zia Insights on a graph give day-over-day changes. Reports comparing a period with the one before are 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	No Scheduled reports are a dashboard as PDF, with no written account. Anomaly and forecast functions serve triggers	Partly SW1, in technical preview, can analyse historical metrics in chat on request. Not in reports	No Machine-learnt anomaly detection in the interface, and Alarm Insights for current alarms. No AI in reports documented	No No AI in reports. Capacity planning, in the Enterprise edition, adds a written summary of its forecast	No Forecast graphs can go in a report. Explain with AI covers one service, in Checkmk Cloud, not a report period	No Forecasts and anomaly bands, and Edwin AI summaries of incidents. No AI-written report documented	Partly Zia Insights write a plain-language summary beside each graph in the interface. Not documented in reports
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	Yes REST API v3, read and write, for resources, alerts, raw readings, graphs and widgets	Yes REST API, read and write, for devices, alarms, graphs and reports. Professional and Enterprise
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 per sensor. Figures for a period need a report or a hand-made API template	Yes XI has host and service availability endpoints, and an SLA endpoint in the Enterprise edition. Core's archive JSON CGI has an availability query	Yes Livestatus state history gives availability, unmonitored time included	Yes An SLA widget's figures come back from the widget data endpoint, with its no-data rule applied	Yes getAvailabilityGraphData returns uptime percentages for today, this week, last month and other periods, per device, interface or monitor
Charts as images from the API	Yes The image the dashboard exports, sized and themed per call	No The API returns JSON only. No method returns a chart image	No SWIS returns data, not images. Charts are drawn in the web console	Yes chart.png and chart.svg, served beside the API	Partly The XI API returns graph data, not images. Core's trends CGI draws a state history graph as a PNG	No The REST API and Livestatus return data, not images. Graph images are rendered internally for notification emails only	Yes Graph endpoints return a PNG with format=image, at a set width and height	No Graph endpoints return data series as JSON, 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, seeing only that user's hosts and services unless allowed all. Address limits not documented	Partly Automation users carry their own role and contact groups. Only the Livestatus port is limited by address	Partly A token carries its user's roles, which can be limited to resource groups. The IP allow list covers the whole portal, not one token	Partly Several keys per user, each limited to modules or named endpoints and to the user's device groups. Address limits are not documented
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 only in a 2022 support article, and Mobile Admin reached end of life in 2021. The 25 minute idle timeout can be switched off per account, which keeps the full console signed in	Yes Free iOS and Android apps keep several accounts to switch between, with push notifications. The new web interface also has a mobile view	Partly XI has a mobile interface that can acknowledge problems, with two-factor rememberable per browser and single sign-on since 2026R1.7. Core relies on community front ends	Partly A dashboard can be shared by a public link, view only, that anyone holding it can open. The responsive layout that fits a phone is in the commercial editions only	Partly iOS and Android apps and a mobile web view, for triage. Staying signed in is not documented, and the apps are bound by the portal IP allow list	Yes iOS and Android apps in every edition, with push notifications that arrive while the app is closed. The app can suppress alarms, so it is not view only
CSV as well as JSON	Yes Every endpoint, with paging fields sent as headers	Partly The API is JSON only. The frontend's Problems page exports to CSV	No SWIS answers in JSON over REST, or XML over SOAP. CSV is not documented	Yes CSV tables, and historic data as CSV	Yes XI's object endpoints return JSON, XML or CSV. Availability and SLA endpoints are JSON only	Yes Views fetched by an automation user come as CSV or JSON, and Livestatus gives CSV. The REST API itself is JSON only	Partly The data endpoints return CSV as well as JSON. Other API resources are JSON, and reports export as CSV	Partly The API returns JSON only. Reports export from the interface as Excel or PDF, and device lists as CSV
Running it
What you have to host	Nothing. GEN runs the service end to end	Self-hosted or cloud A Linux server and database, with optional proxies, or Zabbix Cloud	Self-hosted, Windows Windows Server, with Microsoft SQL Server on Windows or Linux, plus polling engines. SaaS is a separate product	Windows or SaaS A Windows core server and probes, or PRTG Hosted Monitor	Self-hosted only A Linux server, on premises or in the customer's own cloud. No vendor-hosted edition is offered	Self-hosted or cloud A Linux server, appliance or Docker, or Checkmk Cloud	SaaS plus collectors The platform is SaaS only. Collectors run on your own Linux or Windows servers, or in a container, one or more per location	Self-hosted only A Windows or Linux server with the bundled PostgreSQL or Microsoft SQL Server. Enterprise adds a central server and a probe at each site. No vendor-hosted edition documented
How it is charged	Per read, from £0.00002, invoiced monthly in arrears	Free, or cloud tier Free software (AGPLv3) with optional support. Cloud by values-per-second tier	Per node, annual Node-based subscription on multi-year contracts, billed annually	Sensor tiers, annual Subscription in sensor-count tiers. Freeware up to 100 sensors	Free or per node Core is free. XI is licensed per node, with annual maintenance and an optional Enterprise add-on	Per service Per service, by annual subscription, or monthly in Checkmk Cloud. Community edition is free	Per Hybrid Unit Per Hybrid Unit, one collector-monitored device, a month, in Essentials, Advanced and Signature tiers. Edwin AI and several modules are add-ons	Per device, annual Per device, by annual subscription or a perpetual licence with yearly maintenance. Standard, Professional and Enterprise editions

Yes Partly No NA: not applicable, the product has nothing the question could apply to NF: not found in the documentation, but likely. Where it is silent and unlikely, we say No Scroll the table sideways on a small screen

Left out on purpose

No discovery sweep, and no borrowed templates.

Two features the established monitors lead with are missing from Oversight by choice. Both put sensors on your estate that nobody chose, with thresholds nobody set, and a sensor nobody chose is an alarm nobody believes. Knowing your devices is the job. A monitor should not guess it for you.

Discovery and stock templates

A sweep finds everything that answers. Every address, interface and service in the range, each with a default set of checks. The unused switch port, the printer's web page and last year's test VM all become sensors.
It is a scan of your network. Intrusion detection blocks the collector, and then everything it watches goes dark. The usual fix is to exempt it, or the whole LAN, which makes the one machine with credentials and reach into every subnet the one your IDS ignores.
A stock template is somebody else's guess. Hundreds of items per device, thresholds set for an estate that is not yours, and triggers nobody on your team has read.
Then the alarms are learnt to be ignored. The dashboard is never green, and the failure that matters arrives looking like all the others.

The Oversight way

You add what you know. Each device by name, with the checks it actually needs and nothing it does not.
Your template, from a device you trust. Set up one switch properly, its sensors, extractions and rules, save it as a template, and every one like it starts from there.
Explained before it is applied. A template can point to a knowledge base article that says what each check is for and how to set it.
Every alarm is one somebody asked for. So when it fires, it is believed.

Secure by construction

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.

Pay for what runs

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.

Sources for Zabbix 50

Sources for SolarWinds 58

Sources for PRTG 53

Sources for Nagios 42

Sources for Checkmk 52

Sources for LogicMonitor 65

Sources for OpManager 55

Comparison drawn from each vendor's published documentation, checked on 2 October 2026. Zabbix, SolarWinds, PRTG, Nagios, Checkmk, LogicMonitor and ManageEngine OpManager 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.

One poller guesses.Oversight's probes agree.