Type: explanation · Last reviewed: 2026-07-17
Storing data is only half the job — an operator needs to know the moment a signal goes out of bounds, not when they next open a chart. Pulse Historian's monitor is a background engine that continuously evaluates rules against live data and raises an alarm event when a condition holds. This page explains the model — what a rule is, how an alarm opens and closes, and where the results go. For the exact types, endpoints, and schemas, follow the links down to Monitor (reference) and the Monitoring API.
The monitor runs a tick per enabled collection on a timer (default every 1 000 ms). On each tick it reads a short recent window of data for the collection's tags and asks every rule: does your condition hold right now? A false → true transition opens an alarm; true → false closes it.
A rule watches one tag and compares it against a threshold using a comparison (>, ≥, <, ≤, =, ≠). What differs between rule types is how many of the points in the window must breach for the alarm to fire:
| Rule type | Fires when… | Use for |
|---|---|---|
| AllOfN | every point in the window breaches | steady, unambiguous limits |
| KOfN | at least k of n points breach | tolerate brief spikes / noise |
| Percentage | at least X % of present points breach | noisy signals, sample-rate-independent |
| GOAT | value approaches a known record/limit within a margin | "greatest-ever" / approach-to-limit warnings |
Two more knobs shape evaluation:
Skip (ignore, the default), FailOpen (treat missing as a breach), or RequireMinPresent (only evaluate if enough points are present).Under the hood → Monitor § Key types · rule config schemas in the Monitoring API.
When a rule's condition first holds, the monitor creates an AlarmEvent with status OPEN, recording the value that tripped it, the threshold, and the time. While it stays open, each tick updates the peak value. When the condition clears, the event is set CLOSED with a close time and computed duration.
Every alarm is also mirrored into the deviations table (and linked to an incident), so the same event is visible to dashboards, reports, and Pulse Copilot's incident tools — not just the alarm API. Open alarms survive a restart: on startup the monitor reloads everything still OPEN so an alarm that opened yesterday isn't silently forgotten.
Under the hood → Monitor § AlarmEventTracker.
Opening an alarm doesn't just write a row — it also raises a notification, so an operator finds out without watching the alarm table. The monitor is the notifications engine's producer: a >-comparison breach becomes an error-severity notification, other breaches a warn, and a clear an info. From there it fans out to a desktop toast, the navbar bell badge, any open browser session (live over SSE), and optionally email.
How that reaches the right person, and what survives a restart or a missed window, is its own topic → How you get notified.
You rarely create rules by hand. When a tag's metadata (tagmeta) is saved with a low/high limit (limLo / limHi), the monitor automatically creates the matching threshold rules for it. Change the limit later and the old auto-rule's open alarms are force-closed and new rules take over — so the alarm configuration tracks the engineering limits without a separate step.
Under the hood → Monitor § auto_rules · limits are set via tagmeta CRUD.
Using the canonical dataset (acme-power / plant-1 / boiler-2 / default_grid):
steam_temp's limHi = 540 (°C) in the tag metadata. The monitor auto-creates an AllOfN, > 540 rule for steam_temp on boiler-2.trigger_value (say 543.2) and the threshold.peak_value is updated each tick. A deviation row is created and surfaced on the boiler dashboard.clear_value and a duration_ms of, say, 6 minutes.Querying /exactapi/monitor/alarm/events for that window now returns the closed event with its full lifecycle. Exact request/response shapes → Monitoring API § Alarm events.
monitor rule · alarm event · collection · tag