Anomaly alerts
An anomaly alert flags when a signal Ledger already tracks — the number of devices reporting in, or how much of your fleet a security tool covers — moves in a way that is statistically unusual for your account's own history, not just "different from yesterday."
What triggers an alert
Ledger watches two kinds of signal:
- Device count — a jump or drop in the total number of devices reporting in, compared to the account's own recent trailing history.
- Coverage — for RMM, Intune, EDR, DNS filtering, billed count, and blended coverage, Ledger watches the rate of change — how many points coverage moved — rather than a single day's percentage. Blended coverage's rate of change is the same drift velocity your trend line shows.
Either way, the test is the same: is today's value (or today's rate of change) statistically unusual against that signal's own trailing history for this account? An alert means sudden, not merely bad: a decline that has been going on at a steady pace for weeks is part of that history, so it will not keep firing — the trend line is where a steady drift shows up.
Detection runs daily; delivery runs weekly
Ledger checks for new anomalies once a day, right after that day's snapshot is taken. If a signal is still anomalous the next day, and the day after that, each of those days gets its own alert — a persisting issue is not silently swallowed into a single row.
Delivery is different: the anomaly digest email goes out once a week, on Mondays. Rather than emailing you the moment something is detected, Ledger batches everything currently due into one weekly summary. Within that summary, several days' worth of alerts for the same underlying issue (the same scope and the same signal) show up as one line, noting how many days it has been flagged for — never one line per day.
Repeat digest entries
An alert that is still open when the next weekly digest runs is included in that digest again. What actually stops it from showing up in a future digest is acknowledging it.
Acknowledging an alert
Acknowledging one alert also acknowledges every earlier still-open alert for that same scope and signal, up through the one you acknowledged — so acknowledging today's row for a persisting issue clears out the whole run of daily rows it left behind, not just the one you clicked. If the same signal fires again on a later day, that is a brand-new open alert, unrelated to whatever you already acknowledged.
Status values
An alert is either:
- Open — detected, not yet reviewed.
- Acknowledged — a person has reviewed it.
The status filter offers Open, Acknowledged, or All.
The alerts screen lists every alert row Ledger has written for your account that matches your filters — including the older daily rows behind a persisting, now-acknowledged issue, not only its most recent row.
What never fires
Ledger would rather report nothing than report something false:
- If the connector behind a signal is stale or not healthy, that signal is skipped for that day rather than compared against unreliable data.
- A signal needs a minimum amount of stored history before it is evaluated at all; too little history and it is skipped, never guessed at.
- A signal whose history has never moved at all is skipped. The method scores a change against how much that history normally varies, and a perfectly flat history has no variation to score against.
- DNS-filtering coverage has no connector behind it, so this signal never fires.
- A day where blended coverage's own denominator cannot be determined is left out of that signal's history entirely, rather than counted as zero.
The alerts screen
Getting there. The home screen has an Anomaly alerts link alongside Exceptions, Audit log, and the other operational views.
Filtering. Client, status, and signal filters narrow the list, and each is reflected in the page's URL, so a filtered view can be bookmarked or shared with a teammate the same way every other filtered screen in Ledger works. A row with no client (a customer-wide signal like device count) shows as "Customer-wide" rather than blank.
Acknowledging. Every still-open row has an Acknowledge button; once acknowledged, the row (and the earlier same-scope, same-signal rows it closed out) no longer show the button.
Exporting. Export follows the same CSV/XLSX conventions as every other view — the exported rows always match exactly what your current filters show on screen.