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, and says in plain English what has happened and how urgent it is.
AI analysis, hosted by GEN. Alarms open with a written overview, and scheduled reports explain the trends in your data. It all runs in GEN's own datacentres, with nothing sent to a third party and no prompt logged. Read more
message per rule, however much of the estate an incident takes down
from a result arriving to a decision about what it means
inbound ports opened for a probe. Probes only ever connect out
a month to ping a host every minute. No licence, no tiers
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.
- 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
Every vantage point can reach it. There is nothing to say, so nothing is said.
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.
- Optionally, the message opens with a written overview in plain English: what has happened, where, what it probably means and how urgent it is. The detail follows as usual.
- Charts and the poll log from fifteen minutes before the alarm travel with the message.
- Nobody acknowledges, and the alarm climbs after the minutes you set: to a second team, by a different channel. One acknowledgement, from the dashboard, the phone or the API, stops it at every tier.
- An uplink that fails alarms once. Everything that depends on it is held, in a colour of its own, rather than alarming as well.
- 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.
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
A threshold says something has broken. Oversight sees it coming.
A router whose memory has crept up for three weeks has passed every check anyone set, and it is going to fall over. Each reading on the way up was fine on its own, which is exactly why no threshold, however cleverly set, will ever catch it. Oversight learns how each sensor you choose normally behaves, and says when it starts behaving differently: a drift that persists, or a day that looks nothing like the usual Tuesday.
- Different, not broken. Two new states: ABNORMAL for a sensor that is going somewhere, UNUSUAL for one that is somewhere odd for the time of week. Both count as working, both have their own quieter colour, and neither wakes anybody unless you ask it to.
- Persistence beats magnitude. A single reading never produces a finding. A spike that reverts is the internet having a moment; 20ms, then 30ms, then 50ms over two days is the finding.
- The threshold is measured, not set. No three sigma, no twenty per cent. How far is too far comes from each sensor's own history, from each vantage point, on each time scale.
- Only where you ask. A setting per sensor, off by default. Analysis run over everything gives everything an "unusual", and people soon learn to ignore it.
Day up 4% beyond usual
Week up 12% beyond usual
Month up 19% beyond usual
Year too early, 5 months held
State RISING ABNORMAL
Detail 21 days, and no threshold
crossed
Usual about 500 on a Tuesday,
14:00 to 15:00, 20 weeks
Today 1,000, four windows
running UNUSUAL
Detail A level, not a trend. It
clears when it comes back
Days, weeks and months together
Every time scale is judged against its own history, and they must agree in direction before anything is said. A creep shows on the day first, then the week, then the month, which is the order that makes it worth catching.
Several witnesses, one verdict
A standard deviation, a robust spread and the movement of the mean each have their say, and a finding needs them to agree. One statistic on its own is only a threshold in disguise.
The probe can be the finding
Every vantage point keeps its own baseline. In the first fortnight of history, three checks on three devices went from 1ms to 6ms to connect over nine days, all from one probe. From a second probe they went the other way: it was the probe's own host that was failing.
Years of history, kept small
Readings are rolled up into fifteen-minute and daily tiers holding everything a later statistic needs, so "25% more CPU this month than last" still answers years on, long after the raw readings have gone.
The estate on your phone, in one tap.
An alert at the wrong moment is worth little if looking into it means signing in and finding an authenticator code before it expires. Oversight has a light mobile dashboard, on the home screen like an app, with no app to install. Pair the phone once from your desktop and it stays paired, behind a PIN of your own. It opens on the alarms themselves, named, worst first, with how long each has been failing and what it sits on, rather than a count to tap through, and one tap acknowledges an alarm. The estate, readings, history and the poll log are all there too, view only: nothing in the estate can be changed from a pocket.
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. Proxmox Backup Server is watched alongside.
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 and Windows agents
Judge the host where the context is and say what is wrong: an array short of a member, a filesystem gone read-only, RPC slowing on a Windows server before it collapses. They answer reads and can do nothing else, and the Windows agent can send its event log on as syslog. Read more
Echo tests for suspect links
A small echo at the far end of a leg, and the probe measures the path to it: loss in each direction, jitter, gaps, throughput and retransmits. Rain fade on a satellite link shows on a chart. Read more
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 files on an NFS or SMB share or a probe's own mount, by size and age, never contents. 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 and Asterisk endpoints and trunks, 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.
Readings pushed in
For kit nothing can poll. Anything that can run curl or wget pushes its own reading, judged by the same extractions and rules as every other check. Silence past its window is no data, never health.
Both directions, any mail system, and no login to anything.
The usual way to prove 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 in the monitoring system and, on modern hosted mail, registering an app for OAuth2 or carving an exception out of MFA. All that, and it still proves only one direction. Oversight sends a real, signed message in through your MX, and your mailbox forwards it straight back out through your own outbound route. One message proves mail is reaching you and leaving you.
No login to anything
GEN never signs in to your mail. No IMAP or POP3 left open, no service account, no OAuth2 app registration, no exception to MFA, and no password of yours held anywhere.
Any mail system
Exchange, Microsoft 365, Postfix, a hosted mailbox or an appliance. If it can forward a message to an outside address, it can be tested end to end. One way needs nothing at all.
Both directions, one test
In through your MX, filters and mailbox, and out through your own relay, in a single message. When it does not come back, the outcome shows which half to look at.
To mailtest@example.com
MX mx1.example.com
TLS TLSv1.3
Outcome RETURNED OK
Detail Returned in 3 seconds
To sales@example.org
MX mail.example.org
TLS TLSv1.2
Outcome LOST CRIT
Detail Accepted but not back within
10 minutes
- 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.
- 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.
- Nothing to install. A forwarding rule is all it takes, ideally on a mailbox kept for the purpose. The test runs from GEN, with no probe involved.
- 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.
The host knows what is wrong with it. The agent says so.
Most agents ship hundreds of figures to a central server, where a template guesses what they mean. Oversight's agents do the judging on the host, where the context is: whether a filesystem was writable an hour ago, which interfaces have ever had a link, whether a Windows server's RPC calls are taking ten times as long as usual. What they serve is a verdict, nothing wrong or what is wrong and how badly, in words the person fixing it can act on. They send nothing of their own accord: a probe asks, and the agent answers. The one exception is the Windows event log, forwarded only where it is set on the server itself.
- Red means not working, amber means look soon. An array that has lost a member is red at once. A disk throwing errors, a slow member or a rebuild is amber. Nothing is judged on how busy the host is.
- 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. A reboot gets five minutes for mounts and links to arrive.
- It answers when the host cannot. Every reply comes from what has already been sampled, so a hung NFS server or a stalled disk never leaves a request waiting.
Alarm green OK
Alarms 0
Status
Load 0.42 0.38 0.35
Alarm red CRIT
Alarms 3
Status md0 degraded, 1 of 2 members
missing; 45 zombies, up 30 in
30 min; /mnt/pve/nfs1 write 900ms
- Storage. Arrays degraded or rebuilding, disks offline or slow, a mirror member far slower than its siblings, latency judged by disk type, iSCSI, multipath and NFS.
- Filesystems. Every fstab entry mounted from the right device, read-only when it should not be, unresponsive, full, or due to fill within twelve hours.
- Memory and processes. OOM kills, memory pressure, swap being read back, zombies accumulating, and hung processes piling up in uninterruptible sleep.
- Services and network. Failed systemd units, crash loops systemd keeps papering over, lost links and bond members, a port renegotiated slower, and a full conntrack table.
- Windows, the way Windows fails. Commit charge heading for its limit, RPC, DCOM, WMI and LSASS slowing before the collapse, crashes with their stop code, services crash-looping, VSS failing and a broken domain trust. On a domain controller, whether AD answers.
- Events from a signed list. Windows events are matched against a list GEN signs, so a new Windows release is a new file rather than a new agent, and nobody can write a filter of their own into it. Name up to twenty events of your own, and the agent alarms when one appears.
- The event log, as syslog. The Windows agent forwards the logs you choose, warning and worse, everything, or audit failures only, to Oversight's syslog sender or any syslog server, with the channel, event ID and level as fields a rule can match. No third-party forwarder, and set on the server alone.
- It answers, it never reports. The agent listens on one port and replies only to a request carrying its token from an address it allows. It can be bound to a private mesh interface, so it is never on the public network at all. Forwarding the Windows event log is off unless set on the server, and then goes to the one syslog server named there.
- Read only, structurally. No exec, no plugins, no custom checks and no write endpoint, and none will be added. That is how "read-only" agents elsewhere came to run arbitrary commands.
- No root, no administrator. Linux runs as its own unprivileged user; Windows as a service account that can read the event log and performance counters. Neither serves process lists, users or installed software.
- Everywhere it is needed. Servers and VMs, Synology NAS units, 32-bit ARM boxes and NVIDIA Grace Blackwell GPU hosts from one Linux binary; Windows 10 and Server 2016 onwards on x64 and ARM.
Is it the link? Put an echo at the far end and find out.
A ping says a link is up. It does not say the 4G backup drops one packet in fifty, that the satellite link loses more every time it rains, or that the leased line gives a tenth of its speed in one direction. Run the echo on any box at the far end of a suspect leg, point a probe at it, and the probe measures the path both ways, as often as you like, for as long as it takes. Move it along the path, and the fault is found.
- Loss, split by direction. A numbered UDP stream, with the echo counting what it received, so loss on the way out is told apart from loss on the way back. Out of order, duplicates and corrupted packets are counted apart.
- Rain fade, not a handover. Scattered loss leaves out any single gap over 300 milliseconds, so a satellite handover does not read as a bad link and a dirty dish or heavy rain does.
- Throughput both ways. A TCP transfer up and then down, with the speed, stalls and retransmits for each direction, and every byte checked against a known pattern.
- Two echoes, one answer. One near and one far on the same path: a fault seen on the far one and not the near one sits between them.
Packets 1,000 sent, 978 back
Lost up 9, down 13
RTT 31 / 48 / 162 ms
Jitter 7.4 ms
Gap longest 41 ms
Loss 2.2% scattered WARN
Up 94.2 Mbps, 0 retransmits
Down 95.8 Mbps, 0 retransmits
Stall longest 3 ms
Corrupt 0 bytes OK
- Nothing to set up. One small binary for Linux, Windows or macOS, run as it comes. It listens on port 29732 for both tests, and a scan for that port finds every echo you have placed.
- It reflects, and nothing more. It holds no credentials and knows nothing about the host to give away, and a reply is never larger than the packet it answers.
- For private legs. Your LANs, WAN links, tunnels and backup circuits. It is not meant to face the internet, and GEN runs no public echo.
- Quick checks or standing evidence. A thousand packets every five minutes costs next to nothing; raise it to ten thousand a minute to pin a fault down, or leave it on a link that is always suspect.
A site's logs stay on the site. Only what matters reaches Oversight.
A normal site sends hundreds of thousands of syslog lines a day, nearly all of it firewall logging, monitoring systems logging in and routine chatter. The usual answer is to ship all of it somewhere central and search it there. Oversight's senders work the other way: rules you write pick out the few lines that matter where they are written, and only those cross the internet, every five minutes. On a good day nothing is sent at all, and the full day's record stays on the site for when an alarm needs its context.
- Syslog for a whole site. One small sender on a Linux machine at the site takes the syslog from every router, switch, firewall and UPS card on the LAN, and keeps it in a file per day. No rsyslog, syslog-ng or logrotate.
- A host's own logs. Log files followed through rotation, the systemd journal, or a report piped in from cron. Ready-made rules for who logged in and what fail2ban banned, and your own for anything else.
- Windows from two angles. The Windows agent forwards the event log to the syslog sender, whose rules pick out the events that matter, or alarms by itself on the events you name.
- A silence is never a quiet day. A stretch when nothing arrived is marked among the lines, and GEN is told when a sender stops.
- A rule that catches too much says so. A device sending more than a tenth of its lines, or a batch over the limit, shows in orange. A dry run over a month of real log shows what a rule would send before it is relied on.
23:56 switch-core flood
ether8 excessive broadcasts/
multicasts, probably a loop
09:16 router link
ether1 link up
09:15 router link
ether1 link down
12:52 ssh root from 172.16.128.40 09:06 su root, by admin
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. Server to server, and read only unless a key is made to do more, 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.
- Push and acknowledge, where a key allows. Kit nothing can poll pushes its own readings, and a system that takes alarms by webhook acknowledges them, so a playbook already dealing with one stops the escalation.
- 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.
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,
"readings": [
{"group": "London", "acq": "GOT",
"values": [{"name": "Offline",
"unit": "nodes",
"value": 1}]}
]}
]}
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.
Nothing gets in.
Monitoring touches everything, so it must never become the way in. Probes only send: every probe is run by GEN, reaches out rather than listening, and holds nothing on disk that would help anyone who took it. Agents only answer: each listens on one port, replies to reads from the addresses it allows, and can do nothing else. The only thing either sends unasked is the Windows event log, where it is set on the server itself.
- Probes connect out, over HTTPS. 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.
- Agents answer reads, and nothing more. A token and an address allow list, no exec, no plugins and no write endpoint, unprivileged, and optionally reachable over a private mesh only. Event log forwarding, if wanted, is set on the server and sends to one address.
- An echo only reflects. It holds nothing and reveals nothing about its host, and never replies with more than it was sent.
- Log senders only send. They connect out over HTTPS with a token GEN has registered, never need root once installed, and listen for nothing but the site's own syslog.
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 read | Credits |
|---|---|
| File on the probe host, Ping | 1 |
| DNS lookup, FTP file fetch, IMAP4 banner, Linux agent, MongoDB command, MySQL / MariaDB query, NFS file, Pushed reading, RDP negotiation, SIP OPTIONS, SMB file, SMTP banner, SNMP, TCP echo transfer, TCP port, UDP echo stream, Windows agent | 2 |
| HTTP(S) | 4 |
| Email delivery | 6 |
| A user function reduces the response | +4 |
| Store the raw response | +2 |
- Rules, schedules, templates, escalation, email, Matrix, XMPP, 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 most monitoring does, and what Oversight does instead.
Monitoring you can believe at three in the morning.
Used in our data centres, used across our clientbase, used everywhere