Trends
The Trends screen is the QBR time-series view: three line charts built from once-a-day stored snapshots, so you can see whether a client's coverage and open exceptions are getting better or worse over time, not just where they stand today.
The three lines
- Exceptions by severity -- five lines, one per severity level (critical, high, medium, low, info), counting that day's open exceptions.
- Coverage % -- five lines, one per device matrix category (RMM, Intune, EDR, DNS, Billed). Each point is that category's present device count divided by the day's total device count, plotted over time. It counts every device in the total, while the per-client summary export's Coverage line and this page's own Blended coverage line below count only devices where the category applies (excluding not-applicable and count-only devices, per the section below). A client with an out-of-scope or count-only category will therefore see this line read lower than those two.
- Blended coverage -- one line: a single number per stored day that answers "is this client's coverage, overall, getting better or worse," without making you eyeball five separate lines against each other.
How blended coverage is calculated
For each stored day, Ledger takes every matrix category that's
applicable to the client -- present, present-stale, or missing --
works out that category's own present / applicable percentage, and
averages those percentages across categories. It's the mean of
per-category coverage numbers, not one big present-over-total fraction
across every device and category at once.
Two of the device matrix's five cell states are deliberately left out of "applicable":
- "—" Not applicable -- the client doesn't use that source category at all, so there's nothing to measure. Counting it would make a client who simply doesn't buy DNS filtering look like they have a DNS gap.
- "◐" Count-only -- the Billed column for a client whose PSA agreement
bills by quantity rather than by named device. Per-device billing status
is genuinely unknowable there -- neither a real "✓" nor a real "✗" -- so
it can't count as covered or missing without inventing an answer Ledger
doesn't have. A count-only Billed column contributes nothing to the
blended mean; it is never averaged in as
0%.
"✗" Missing still counts toward the denominator, on purpose: a category the client is scoped into, with a device absent from it, is a real, honest gap, and blended coverage has to reflect it the same way the matrix does.
Nothing to average is not zero
A day where every one of a client's categories is not-applicable or
count-only -- a brand-new client with no source connected at all, say --
has zero qualifying categories to average, and that day's blended-coverage
point is left out of the line entirely -- the same visible break in the
chart an ordinary missing-snapshot gap produces (see "Gaps are gaps"
below), never a plotted 0%. Having nothing to average is not the same
claim as "your coverage is zero," and the chart never conflates the two.
That's different from a category the client genuinely has no coverage
for: if a client is scoped into EDR and none of their devices report to
it, that category's ratio is a real 0%, and it's averaged in like any
other ratio -- it can and should pull the blended number down. A day with
nothing at all to average produces a gap in the line, not a zero; a real
zero is always plotted, never hidden behind a gap.
Drift velocity
Beside the Blended coverage heading, a small badge answers the question the line above it raises but doesn't quite spell out: not just "what's the number today," but "which way is it moving, and how fast." It's a plain week-over-week comparison -- Ledger takes this client's average blended coverage over the most recent 7 stored days, takes the average over the 7 stored days before that, and subtracts. The result reads in points per week: "up 2.3 points a week" means this week's average is 2.3 points higher than last week's, not that any single day jumped by that much.
It takes 14 stored days of blended coverage before a number shows at all. Until then the badge reads "Not enough history yet" -- no arrow, no number, no guess standing in for data Ledger doesn't have yet. A day whose blended coverage couldn't be computed (see "Nothing to average is not zero," above) doesn't count toward either 7-day average and doesn't count toward the 14-day minimum either -- it's treated exactly like a day with no snapshot at all.
Once there's enough history, small week-over-week wobbles aren't called a trend: anything within half a point either way (-0.5 to +0.5 pts/week) reads as flat rather than a false "improving" or "declining" on noise that isn't really a direction -- the badge still shows an arrow and the exact points-per-week figure, just a straight right-pointing arrow instead of up or down. Outside that band, the arrow points up for improving or down for declining, with the same points-per-week figure either way. This is the same number, computed the same way, that shows up in this client's QBR narrative and scheduled-report sentence -- one formula, read everywhere it's mentioned, never a second calculation quietly disagreeing with the first.
Range, client filter, and export
The range picker (30 / 90 / 180 days) and the client filter both round-trip through the URL, the same shareable-link pattern the device matrix and billing reconciliation screens already use. Selecting "All" clears the client filter and shows the customer-wide series instead of one client's.
There's no dedicated Trends export. When a specific client is selected, the export button reuses that client's own per-client summary export rather than a separate Trends endpoint, and it's hidden entirely when the client filter is set to "All," since there's no customer-wide equivalent of that export.
Gaps are gaps
A day with no stored snapshot renders as a visible break in the line --
never a value of 0 and never a straight line interpolated across the
missing day. If a client's sync was down for three days, the chart shows
a three-day gap, not a number Ledger never actually measured.