Infrastructure monitoring from GEN

Every alert earned.
Every outage explained.

Oversight watches servers, clusters, storage, networks and services from as many places as you choose, and only raises the alarm when the evidence agrees. When something does break, you get one message that shows the cause and everything it took down with it.

Outbound HTTPS only Proxmox and Ceph aware Email tested in and out Priced per read Managed end to end by GEN
ALL CLEAR
OK Warning Critical No data Paused
The estate wheel: sites, groups and devices, with your logo at the centre. Illustrative estate.
1

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

15s

from a result arriving to a decision about what it means

0

inbound ports opened. Probes only ever connect out

£0.86

a month to ping a host every minute. No licence, no tiers

Consensus, not a coin toss

One probe that cannot reach a server tells you about the probe.

Oversight attaches each check to probe groups in different places, forms a separate view from each, and decides by how many agree. One failing view is the internet having a bad day. Several is a real problem. All of them is an outage. Try it.

Click a probe group to take its view down
  • The same rule applies at every level. A server goes red on any failed check; a resilient switch fabric shrugs off one lost path.
  • A group that did not report is left out of the count, never counted as healthy.
  • Every bucket can map to any state, per object, so the mapping suits the thing being watched.
Failing views
0 of 5
Bucket
None
The sensor is
OK

Every vantage point can reach it. There is nothing to say, so nothing is said.

One alarm, not forty

The cause and its consequences, in one message.

When a check fails, its device, group and site can all follow. Most monitoring sends four alerts, or "Sensor X is down, and 45 others". Oversight folds the 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 wants: HTML email, Markdown for Matrix and Rocket.Chat, JSON for webhooks, a short summary for SMS.
  • Charts and the poll log from 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.
  • Send any rule as a test, to its real recipients, before three in the morning tests it for you.
ALARMNOC critical · 3 new, 1 cleared 09:42 UTC
Primary DC                        WARNProxmox                         CRIT  2 devices
  ├ pve-02                        CRIT  4m
  │ ├ Cluster quorum    offline 1  CRIT
  │ └ Guests  133 proxy stopped    CRITpve-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
Built for the estate you actually run

It understands clusters, storage and guests, not just ports.

Oversight was built from scratch around modern infrastructure. It reads what your platforms say about themselves and turns one fetch into as many separate alarms as the answer deserves.

Proxmox VE

One read of the cluster returns every VM and container, each with its own rule. A guest in backup, migration or snapshot reads as exactly that, not as a failure. Name a group of guests and one rule covers it, with who is down in the alert.

Ceph

Health and the checks raised, monitor quorum, OSDs up and in, placement groups not active and clean, and manager availability. Quorum and node counts for the cluster, including a node missing from the list altogether.

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.

One fetch, many alarms

Five checks reading five fields of one document make one request. A bulk answer fans out into named values, per guest or per disk, each with thresholds of its own. SNMP checks on one target share a single GETBULK.

SNMP, with MIBs as data

Pick an object from vendor MIBs instead of typing an OID. Type, unit, scaling and value names fill themselves in: tenths of a volt chart as volts, and a bare 2 reads "2 (warning)". v1, v2c and v3.

Any REST or SOAP API

Method, headers, body and TLS under your control. Extract by JSON path, XPath with namespaces, regex, header, status or size. Save a working check as a template and fill in the rest of the rack from it.

Databases and files

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

Services, old kit included

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

Email, end to end

Mail in and mail out, proven by one message.

A mail server that answers is not mail that arrives, and mail that arrives is not mail that leaves. Oversight's round trip tests both halves of the route. A real, signed message leaves GEN, crosses the internet and comes in through your MX, filters and relays to the mailbox. Your mailbox forwards it straight back out, through your own outbound route and across the internet to GEN. When it returns, mail is reaching you and leaving you. When it does not, the outcome shows which half to look at.

One test, both directions
GEN Oversight Your MX and filters Your mailbox Your outbound relay In from the internet Back out to GEN delivered forwarded Both halves of the route, and no password to your mailbox
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. 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 to the way in. Lost means your MX accepted it and it never came back.
  • Nobody needs your password. A forwarding rule is all it takes, ideally on a mailbox kept for the purpose. Nothing to install and no probe involved.
  • Signed like real mail. DKIM, from a domain publishing SPF and a DMARC policy of reject, so your filters judge it as they would any legitimate sender.
  • Your rules decide. Every test ends in one plain outcome, and you choose which count as a failure.
  • One way, where forwarding is not possible. The test asks for a delivery receipt and is watched for the receipt or a bounce, with nothing to set up at your end.
  • Our fault is not yours. GEN tests its own mailbox every minute. If that ever stops receiving, tests are held as no data, not failed, and GEN's staff are alerted.
Your data, in your tools

Everything Oversight knows, through one API.

State, readings, history, availability and charts for any object in the tree, from a key made for each integration. JSON or CSV, in flat rows that Grafana's Infinity datasource reads without transformation. Read only and server to server, so a wallboard, a customer portal or an archive reads from it and can change nothing.

  • Tree and state. Every site, group, device and sensor, the change that put each 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 like, or every raw reading, paged.
  • History and availability. Every state change, and availability worked out as the dashboard works it out, with no data kept apart from downtime.
  • Charts. The same image the dashboard exports and a notification carries, sized and themed to fit.
  • Keys you can narrow. To one branch of the estate and to named addresses, IPv4 or IPv6, and revoked the moment you say.
  • A stale key breaks nothing. A bad 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.gen.uk/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,
   "readings": [
    {"group": "London", "acq": "GOT",
     "values": [{"name": "Offline",
                 "unit": "nodes",
                 "value": 1}]}
   ]}
 ]}
Numbers you can defend

Monitoring people keep reading, because it never cries wolf.

No data is never "down"

A check we cannot hear from is grey and labelled as no data. It never drives anything into alarm and never counts against your availability. Coverage is reported beside availability, so you see how much of the time we could see.

A typo wakes nobody

Configuration is validated on save. Anything that still cannot run is reported without the request being attempted, suspended after one try, and flagged where it can be fixed. The on-call rota never hears about it.

Fix a rule, fix the history

Probes return what arrived and every threshold lives centrally. Raw readings are kept exactly, so a corrected rule or unit can be applied to the past instead of living with the old mistake.

The worst rule always wins

Every rule is tested and the worst state reached is recorded. The order rules were written in can never hide a critical behind a warning.

Faults with an owner

Connect and response times are recorded separately, and every failure carries its class: DNS, refused, connect timeout, response timeout, TLS or authentication. A firewall fault never looks like a hung service.

Schedules on local time

Office hours and maintenance windows at fifteen-minute resolution, with date overrides, correct through the clock change. A rule outside its hours keeps what is wrong and sends it when they begin.

Secure by construction

Nothing gets in.

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

  • Outbound HTTPS only. Nothing connects to a probe, and a probe accepts no instruction it did not ask for.
  • Signed on every request. Each probe makes its own ed25519 key at enrolment. We hold only the public half.
  • A pinned uplink. TLS 1.3, always verified, on a connection kept apart from the one that reaches your kit.
  • Credentials in memory only. Sealed at rest, inherited down the tree field by field, 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.
Pay for what runs

Simple checks cost almost nothing. Heavy ones cost what they take.

No per-sensor licence, no tiers and no prepayment. Every read, 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.

Each readCredits
Ping1
DNS lookup, FTP file fetch, IMAP4 banner, MongoDB command, MySQL / MariaDB query, RDP negotiation, SIP OPTIONS, SMTP banner, SNMP, TCP port2
HTTP(S)4
Email delivery6
A user function reduces the response+4
Store the raw response+2
  • Rules, schedules, templates, escalation, email, Matrix, Rocket.Chat, webhooks and tickets are included. SMS and voice are metered separately.
  • A probe group that is down produces no reads and costs nothing.
  • Every check shows its cost per read and a monthly estimate as you configure it.
  • Rather GEN set it up? See services, from £49 an hour.

What would it cost?

Estimated monthly cost
£10.37
129,600 reads × 4 credits = 518,400 credits. Indicative, based on a 30-day month.
The difference, line by line

What most monitoring does, and what Oversight does instead.

The usual approach
Oversight
One probe decides whether it is down
Every vantage point votes, with rules set per object
"Sensor X is down, and 45 others"
One message per rule, drawn as a tree, worst first
A flat licence per sensor or device
Per read, for what actually runs
A threshold fix applies from now on
Raw readings kept and re-evaluated against the fix
No data looks the same as healthy
No data is grey, labelled, and never counted as downtime
Guests in backup or migration raise alarms
Backup, migrate and snapshot recognised as expected
Inbound ports, and agents that can run commands
Outbound HTTPS only, and a read-only agent
A typo pages the on-call rota
Invalid configuration suspended after one attempt and flagged
Checks that a mail server answers
One message proves mail reaches you and leaves you again

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.