Monitors
An overhaul of how a monitor collection is managed, splitting one overloaded screen into surfaces for status, management and event history — then, eight months later, a way to compose monitors out of each other.
Monitors read aggregated data across every pipeline rather than at the edge, which is what lets them hold an organisation-wide threshold and correlate across sources no single agent sees.
Managing a collection means filtering and searching it, snoozing what is noisy right now, and editing a threshold or query in place — without opening each monitor in turn to find out what it does.
Alert history is its own surface, with summary and attribute views of what fired, when, and against which group.
Composite monitors
A composite monitor reads no telemetry of its own. It reads the alert state of up to a handful of other monitors and evaluates a boolean expression over them, so a notification can require co-occurrence: a log monitor firing alone is noise, a pattern anomaly firing alone is noise, both at once is an incident.
Two things make this harder than it looks, and both land in the interface. Each constituent monitor can itself be grouped, so the composite evaluates per group intersection — two groups combined with four yields four under OR and two under AND. Severity resolves by operator too: AND takes the lowest severity among its matches, OR the highest. Both have to be legible before the user has any data to test against.
