Oversight: Modern Infrastructure Monitoring from GEN

Every alert earned, every outage explained

Oversight is infrastructure monitoring built and run by GEN. It watches servers, clusters, storage, networks and services from as many places as you choose, and raises the alarm only once the evidence agrees. When something has genuinely broken, one message arrives that names the cause, shows everything it has taken down with it, and says in plain English how urgent it is.

We wrote it because the products we had used for years kept failing in the same ways: one flaky link calling an outage, alert storms that buried the cause, green dashboards sitting over probes that had quietly died, a mistyped threshold waking an engineer at three in the morning, and a licence that grew every time the estate did.

It is also what we use ourselves. The Proxmox clusters, Ceph storage, mail platforms and network equipment carrying our customers' services are watched by Oversight, so everything described here has been proven on infrastructure we are directly answerable for.

Outbound HTTPS only Proxmox and Ceph aware Email tested both ways, no login Priced per read Managed end to end by GEN

VERSIGHT

The estate wheel: every site, group and device at a glance, with your own logo at the centre. An illustrative estate.

1message per rule, however much of the estate an incident takes down

15sfrom a result arriving to a decision about what it means

0inbound ports opened. Every probe connects outwards only

£0.86a month to ping a host every minute. No licence and no tiers

One Poller Guesses. Probes Agree.

In a traditional monitor, a host belongs to one poller, proxy or probe. That single vantage point decides whether it is down, so when it has a bad day, so do you. Oversight turns the model round. A check joins probe groups in different places, each group forms its own view, and the state is settled by how many of those views agree.

The traditional model

The Oversight model

Failing views	Default state	What it means
Exactly one	OK	One vantage point struggling is the internet, not an outage
More than one, not all	Warning	Something real is happening
Every reporting group	Critical	Nobody can reach it

Probes share the work. Checks belong to the group rather than to a machine, every probe reports in every ten seconds, and a probe that dies has its work picked up by its peers within about two minutes.
Silence is never read as health. A probe group that did not report is left out of the count, never counted as reaching.
Each bucket is yours to map. Two groups failing can be critical for a payment gateway and a warning for a mirror, set per object.

A Rule at Every Step

What counts as critical is a property of the equipment, not of the monitoring system, so Oversight lets you say it at every level. Each level is settled 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 a warning, 5 is critical.
2
Each probe group

Every group forms its own view from those conditions, with a count of failed reads before it will call anything down.
3
The check

The views vote, and ANY, SOME and ALL each map to whichever state suits the thing being watched.
4
The device

Its checks roll up under the same three buckets. A server goes red on any failed check.
5
Group and site

The same rule once more. A resilient switch fabric shrugs off one lost path, and twenty web servers matter only 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. A check we cannot hear from is shown as no data, never drives its parent into alarm, and never counts against availability. Coverage is reported beside the availability figure, so you can see how much of the period we could actually see.
A typo wakes nobody. Configuration is validated on save, and anything that still cannot run is suspended after a single attempt and flagged where it can be fixed.
Fix a rule, fix the history. Raw readings are kept exactly as they arrived and thresholds are held centrally, so a corrected rule or unit is applied to the past as well as the future.
Faults with an owner. Connect and response times are recorded apart, and every failure carries its class: DNS, refused, connect timeout, response timeout, TLS or authentication. A firewall fault never reads as a hung service.

One Incident, One Message

When a check fails, its device, group and site can all follow it down. Most monitoring answers with four alerts, or with "Sensor X is down, and 45 others". Oversight folds the whole incident into one message per rule, drawn as a tree: the site, the group, the device that went critical and the check beneath it that took it there.

Templates repeat per affected object, worst first, in the shape each channel expects: HTML email over your own relay, Markdown for Matrix and Rocket.Chat, JSON for webhooks, and a length-checked summary for SMS.
A whole HTTP request can be a template, so anything with an API is reachable, an n8n flow included.
Charts and the poll log from the fifteen minutes before the alarm travel with the message.
Escalation is a second rule on a worse state, to different people by a different channel.
Recovery goes only to the people who were told about the failure, and repeats are bounded.
Office hours and maintenance windows run on local time at fifteen-minute resolution, correctly through the clock change. A rule outside its hours keeps what is wrong and sends it when they begin.
Any rule can be sent as a test, to its real recipients, before a real incident tests it for you.

ALARMNOC critical · 3 new, 1 cleared 09:42 UTC

Primary DC                        WARN
└ Proxmox                         CRIT  2 devices
  ├ pve-02                        CRIT  4m
  │ ├ Cluster quorum    offline 1  CRIT
  │ └ Guests  133 proxy stopped    CRIT
  └ pve-04                        WARN  1m
    └ Ceph health     HEALTH_WARN  WARN
Offices                             OK
└ fw-01  Ping                        cleared

SMS: 3 down: 2 sensors in pve-02, 1 in pve-04

Explained in Plain English

An experienced engineer can read a week of figures and see trouble coming. Most of the people who receive an alert, or who pay for the monitoring, cannot. Oversight's AI reads the evidence for them and says what has happened, what it probably means and how urgent it is. Nothing is lost by it, because the usual detail follows underneath.

In the message that wakes you. Tick one box on a notification rule and every message opens with the overview, rather than leaving it in a console page nobody is looking at.
It knows what the checks mean. A failed ping on a broadband line means the line is down; a check with no data may be the probe rather than the device.
It summarises, it does not investigate. It is given the alarm's own facts, never your charts, logs or credentials, and says "likely" where it is inferring.
An alarm is never late for it. If the overview takes more than thirty seconds, the message goes on time without one.
Nothing leaves GEN. The models run in our own datacentres. No third-party AI service, no public cloud and no prompt logged. Monitoring data names every host, address and weak point in your estate, and says when it is weak, so it is the last thing that should sit in somebody else's retention policy.

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)

The same writing up goes into scheduled reports. Daily, weekly or monthly on local time, a report reads the series you choose, sets the period against the one before it, and explains what the data shows: the typical level, the pattern, the peaks, the trend and whether anything needs doing. Average, median, 95th percentile and the busiest hours are worked out exactly first, so the AI interprets the arithmetic and is never asked to do it.

Built for the Estate You Actually Run

Oversight reads what your platforms say about themselves rather than asking whether a port answers. One fetch fans out into as many separate alarms as the answer deserves, so five checks reading five fields of one document cost a single request, and SNMP checks against one target share a GETBULK.

Proxmox VE clusters

Quorum, the nodes you expect, and the online and offline ones 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 the expected states they are, and a vanished guest reads as not found.

Proxmox Backup Server

Watched alongside the cluster it protects, so a failing backup is an alarm now rather than a surprise at restore time.

Ceph

Health and the checks raised, monitor quorum, OSDs up and in, placement groups not active and clean, and manager availability.

Linux agent

Per-core CPU, memory, disk buffers, driver state, interfaces, connections, filesystems and full iostat tables. Read only and incapable of acting on the host, so nobody holds SSH keys to your estate.

SNMP, with MIBs as data

Choose an object from the vendor's MIB instead of typing an OID. Type, unit, scaling and value names fill themselves in, so tenths of a volt chart as volts and a bare 2 reads as 2 (warning). v1, v2c and v3.

Any REST or SOAP API

Method, headers, body and TLS under your control, including Redfish, HPE iLO and Dell iDRAC. Extract by JSON path, XPath, regex, header, status or size, then save the working check as a template and fill in the rest of the rack from it.

Asterisk

Every endpoint and trunk, with the names of those down carried into the alert. Name the trunks that must exist and one check watches exactly those.

Databases and files

MySQL and MariaDB queries, MongoDB commands, and FTP or FTPS with login and transfer timed apart. A backup that is present, the right size and eleven days old is a failure, and Oversight says so.

Services, older kit included

HTTP(S), DNS, SIP, SMTP, IMAP4, RDP including whether NLA is enforced, TCP and ping. Firmware stuck on TLS 1.0 can be watched deliberately, per check, without weakening anything else.

Email, Tested Both Ways

The usual way to prove that mail arrives is to sign in to the mailbox and look. That means leaving IMAP or POP3 switched on, keeping a service account and its password inside the monitoring system and, on hosted mail, registering an application for OAuth2 or carving an exception out of MFA. All of that, and it still proves one direction. Oversight sends a real, signed message in through your MX, and your mailbox forwards it straight back out through your own route. One message proves that mail is reaching you and that it is leaving you.

One test, both directions

EMAILRound trip · every 15 minutes

To       mailtest@example.com
MX       mx1.example.com
TLS      TLSv1.3
Outcome  RETURNED                    OK
Detail   Returned in 3 seconds

EMAILRound trip · the way out has stopped

To       sales@example.org
MX       mail.example.org
TLS      TLSv1.2
Outcome  LOST                      CRIT
Detail   Accepted but not back within
         10 minutes

Returned, delivered, relayed, sent, bounced, lost, refused or unreachable

In, as the world sends it. Delivered straight to your MX like any outside sender's mail, so it meets the same DNS, filters, gateway and relays, and a refusal is recorded with the server's own reply.
Out, as your mail leaves. The forward travels your own outbound route to a domain outside yours, so mail that has stopped leaving is caught as surely as mail that has stopped arriving.
It shows which half. Refused, bounced or unreachable points at the way in. Lost means your MX accepted it and it never came back.
Signed like real mail. DKIM, from a domain publishing SPF and a DMARC policy of reject, so your filters judge it exactly as they judge a legitimate sender.
Nothing to install. A forwarding rule is all it takes, ideally on a mailbox kept for the purpose, and the test runs from GEN with no probe involved. Where forwarding is not possible, the one-way test asks for a delivery receipt and watches for the receipt or the bounce.
Our fault is not yours. GEN tests its own mailbox every minute. If that ever stops receiving, your tests are held as no data rather than failed, and our staff are alerted.

Your Data, In Your Tools

Everything Oversight knows is available through one read-only API: state, readings, history, availability and charts for any object in the tree. JSON or CSV, in flat rows that Grafana's Infinity datasource reads without transformation, so a wallboard, a customer portal or an archive can take what it needs and change nothing.

The whole tree and its state, the change that put each object where it is, and the newest reading from every probe group behind it.
Readings averaged with minimum and maximum exactly as the dashboard draws them, per probe group if you want, or every raw reading, paged.
Availability worked out as the dashboard works it out, with time we could not see kept apart from downtime.
Keys made per integration, narrowed to one branch of the estate and to named IPv4 or IPv6 addresses, and revoked the moment you say so.
A stale key is refused, never banned, so an out-of-date dashboard cannot take the probe beside it offline.

GET/api/v1/state · problems only

https://oversight.im/api/v1/state
  ?problems=1&latest=1
X-API-Key: ovs_********

{"endpoint": "state",
 "count": 1,
 "rows": [
  {"id": 4812, "type": "SENSOR",
   "name": "Cluster quorum",
   "state": "CRIT",
   "since": "2026-09-17T09:38:12Z",
   "bucket": "ALL",
   "failing": 3, "reporting": 3}
 ]}

Secure by Construction

Monitoring touches everything, so it must never become the way in. Every probe is run by GEN, reaches outwards rather than listening, and holds nothing on disk that would help anyone who took it.

Outbound HTTPS only. Nothing connects to a probe, no inbound port is opened on your network, and a probe accepts no instruction it did not ask for.
Signed on every request. Each probe generates its own ed25519 key at enrolment, and GEN holds only the public half.
A pinned uplink. TLS 1.3, always verified, on a connection kept apart from the one that reaches your equipment.
Credentials in memory only. Sealed at rest, inherited down the tree field by field, and never written to a probe's disk.
Locked and banned. A probe can be tied to its address, and a bad request bans the address it came from.
Updates that cannot brick. Length, hash and a test start are checked before a new build replaces anything, canary first.
Tenant isolation is enforced in the data layer, and every administrative action is audited.

Pay for What Runs

No per-sensor licence, no tiers and no prepayment. Every read, meaning one result from one probe group for one check, costs a fixed number of credits set by what it involves, and a credit is £0.00002. Invoiced monthly in arrears, so a simple check costs almost nothing and a heavy one costs what it takes. A probe group that is down produces no reads and costs nothing.

Example	Indicative cost
A ping every minute, from one location	£0.86 a month
An email round trip every fifteen minutes	£0.35 a month
A Proxmox guest check, from three locations every minute	£20.74 a month
A website check, from twenty locations every minute	£69.12 a month

Rules, schedules, templates, escalation, state evaluation and delivery history are included and never charged, as are email, Matrix, Rocket.Chat, webhooks and tickets. SMS and voice are metered separately. Every check shows its cost per read and a monthly estimate as it is configured, and there is an estimator for your own estate on the Oversight site.

Against the Established Monitors

The points where Oversight differs most from the products it replaces. Every entry below is taken from that vendor's own published documentation, checked on 16, 17 and 19 September 2026, and the full table with its sources is on the Oversight site.

	Oversight	Zabbix	SolarWinds	PRTG	Nagios	Checkmk
Checks belong to a group of probes, not one collector	Yes A dead probe's checks move to its peers in about two minutes	Partly A host can join a proxy group, but one proxy watches it at a time	Partly One polling engine per node, with standby pools for failover	Partly A sensor belongs to one probe, unless a failover cluster is built	Not documented	No One site monitors each host
The state is decided by how many locations agree	Yes Every probe group votes, and each bucket maps to a state per object	No Proxy groups fail over, they do not vote	No High availability pools are standby, not voting	Partly A failover cluster shows Down (Partial). No quorum setting	Not documented	No One site monitors each host
No data is kept apart from downtime, by default	Yes Grey and labelled, with coverage reported beside availability	Not documented An Unknown state exists. Its place in SLA figures is not documented	Not documented An Unknown status exists. Its place in availability is not documented	Not documented A grey Unknown exists. Its place in uptime reports is not documented	Not documented Unknown and stale results exist. Their place in reports is not documented	Partly Configurable, and unmonitored time can be shown separately
A corrected rule can be applied to readings already taken	Yes Raw readings are kept exactly and the history is worked out again	Not documented	Not documented	Not documented	Not documented	Not documented Annotations reclassify periods. Re-applying thresholds is not documented
The message shows cause and consequence as a tree, worst first	Yes Site, group, device and the check beneath it that took it there	Not documented	Not documented	Not documented	Not documented	Not documented
A plain English overview can lead the message	Yes What happened, where, what it probably means and how urgent	Partly Community add-ons on the vendor's blog. Nothing built in	Partly A chat assistant in technical preview, not in the message	Partly Alarm Insights in early access, not in the message	Not documented	Partly Explain with AI, in the interface and in one edition only
The AI runs on the provider's own hardware, with no prompt logging	Yes GEN's own models in GEN's own datacentres, and nothing is logged	No The add-ons send your problems to Google's Gemini	No Requests go to the vendor's cloud and on to commercial providers	Not documented Where Alarm Insights runs is not documented	Not documented	Not documented It runs in the vendor's cloud. The model is not documented
One test proves mail both reaches you and leaves you	Yes In through your MX, then back out through your own route	Not documented The official template checks the TCP port only	Partly One direction, into a mailbox it signs in to	Partly One direction, into a mailbox it signs in to	Partly One direction, into a mailbox it signs in to	Partly One direction, into a mailbox it signs in to
No login to your mail at all	Yes A forwarding rule is the whole of it, and one way needs nothing	Not documented	No Needs mailbox credentials and a named SMTP server	No Needs an IMAP or POP3 login	No Needs SMTP and IMAP details	No Needs a mailbox login
What you have to host	Nothing. GEN runs the service end to end	A Linux server, database and proxies, or the vendor's cloud	Windows Server and SQL Server, with polling engines	A Windows core server and probes, or hosted monitoring	A Linux server. No vendor-hosted edition documented	A Linux server, appliance or container, or the vendor's cloud

Zabbix, SolarWinds, PRTG, Nagios and Checkmk are trademarks of their respective owners, who are not affiliated with GEN and have not endorsed this comparison. Where a vendor documents nothing either way we say so rather than claiming the feature is absent.

See It for Yourself

Oversight has its own site at oversight.im, where you can take probe groups down one at a time and watch the state follow, work out the cost of your own estate, and read the full comparison against the established monitoring products. It is a managed service, running across four live sites ahead of general release.

Oversight Questions

What is a probe group?

A set of Oversight probes in one place. A check belongs to the group rather than to a single machine, so every probe in it reports in every ten seconds, and a probe that dies has its work picked up by its peers within about two minutes. A check can join probe groups in several different places, and each group forms its own view of it.

How does Oversight decide that something is down?

By how many probe groups agree. By default, exactly one failing view is OK, because one vantage point struggling is the internet rather than an outage; more than one but not all is a warning; and every reporting group failing is critical. A probe group that did not report is left out of the count, never counted as reaching, and each bucket can be mapped to whichever state suits the object being watched.

How is Oversight priced, and what is a credit worth?

Per read. A read is one result from one probe group for one check, and it costs a fixed number of credits set by what it involves. A credit is £0.00002, so a ping every minute from one location costs £0.86 a month and an email round trip every fifteen minutes £0.35 a month. There is no per-sensor licence, no tiers and no prepayment, it is invoiced monthly in arrears, and a probe group that is down produces no reads and costs nothing. SMS and voice are metered separately.

Does the email test need a login to our mail?

No. Oversight sends a real, signed message in through your MX, and your mailbox forwards it straight back out through your own route, so one message proves that mail is reaching you and that it is leaving you. A forwarding rule is all it takes, ideally on a mailbox kept for the purpose, and the test runs from GEN with no probe involved. Where forwarding is not possible, the one-way test asks for a delivery receipt and watches for the receipt or the bounce.

Do we need to open any ports for the probes?

No. Every probe is run by GEN and connects outwards over HTTPS only. Nothing connects to a probe, no inbound port is opened on your network, and a probe accepts no instruction it did not ask for. Each probe signs every request with its own ed25519 key, GEN holds only the public half, and credentials are held in memory, never written to a probe's disk.

Where does Oversight run?

It is a managed service, run end to end by GEN, so there is nothing for you to host. Its AI models run in GEN's own datacentres, with no third-party AI service, no public cloud and no prompt logged. Oversight also watches the Proxmox clusters, Ceph storage, mail platforms and network equipment carrying GEN's own customers' services, and it is running across four live sites ahead of general release.

Monitoring Your Estate

To talk about monitoring your estate, or about moving across from a system you already have, contact us and one of our engineers will take you through it.