Report five numbers for a fleet update: the share of devices on the target release, the share that is unreachable, the time to reach the first and the last reachable device, the rollback or failure rate, and the number of releases still live. A single percent updated hides the devices you cannot see.
Why one percentage misleads
Say 95 percent of reporting devices are on the new release. If a fifth of the fleet has not reported in a month, the true share of the fleet on the new release is far lower, and the unreported fifth is exactly where old, vulnerable releases sit. Always state the denominator.
The five numbers
| Metric | How to compute | What it tells you |
|---|---|---|
| Share on target | Devices on target divided by all known devices | Real coverage |
| Share unreachable | Devices with no check-in within a set window divided by all | Blind spot |
| Time to first and last | Hours from release to first install, and to the chosen share | Speed |
| Failure and rollback rate | Failed or rolled back divided by attempted | Release quality |
| Live releases | Count of distinct releases in the field | Support burden |
Choose windows and write them down
Define "unreachable" in advance: no check-in for seven days, thirty days, or a multiple of the poll cap. Define "target" as the release or any later one, so a newer hotfix does not count as behind. Keep the definitions next to the dashboard.
Link to risk
Add one more view for security work: devices running a release that carries a known exploited or reachable vulnerable component. That number, not the overall percentage, tells you whether to act today. The release SBOMs supply the component list, and the device map supplies the count.
Steps
- Build the device map first. Metrics need a reliable denominator.
- Compute the five numbers weekly, and daily during an emergency rollout.
- Trend the count of live releases. If it only rises, you are accumulating support debt.
- Review the unreachable group by hardware model and region to find patterns, such as one carrier or one batch.
- Report the same numbers to engineering and leadership, so there is no second, rosier version.
What not to report
Skip counts of updates sent, which say nothing about installs. Skip averages that blend fast and slow devices, because the slow tail is the story. Use percentiles or the time to a chosen share instead.
Safeguard can show which stored releases carry known vulnerable components, supplying the risk view above. See the free scan at gold.safeguard.sh/scan.
A small example
Imagine 1,000 known devices. Seven hundred are on the target release, two hundred are on older releases but reporting, and one hundred have not checked in for forty days. The honest line reads: 70 percent on target, 10 percent unreachable, 20 percent pending. Reporting 78 percent of reporting devices as current would be true and still misleading. Present the first version, and add the vulnerable component count for the pending and unreachable groups.
Quick check
What denominator should coverage use?
All known devices, including those that have not reported. Show the unreachable share on its own.
Is the average time to update a good metric?
It hides the slow tail. Use the time to reach a chosen share, such as the first and last reachable device.
Last reviewed: 19 October 2026.
