Sensor rollout rings
Creating a staged rollout ring on a host group, target percentage, pause and resume, the adoption bar — and the one thing to know before you rely on it: nothing in update delivery reads a ring's decision yet.
A sensor rollout ring scopes a staged sensor-update target percentage to one host group, rather than to your whole tenant. It is a distinct feature from the tenant-wide staged rollout described in The sensor update channel and staged rollout — that mechanism reuses internal/sensorupdate's own channel/pin/rollout logic across your entire fleet; a ring layers a second, host-group-scoped target on top of it, reimplementing the same idea (a deterministic hash bucket per sensor) independently, scoped narrower.
Creating a ring
From the Rollout rings panel on the consolidated /xdr/policy page, creating a ring needs a host group, a ring name (matching a policy bundle's update_ring field, e.g. stable, beta, nightly), a target version, a target percentage and a failure threshold percentage. A host group may have at most one ring — the underlying table enforces one rollout per (organisation, host group).
InRollout — the function that decides whether a given sensor falls inside a ring's current target — is pure and deterministic: raising the target percentage only ever adds sensors to the rollout, it never reshuffles who is already in it. A sensor scoped to a dynamic host group is evaluated against that group's static-membership snapshot at query time, the same limitation described for other host-group-scoped surfaces in Policy objects and host groups.
The adoption bar, pause and resume
Each ring shows an adoption bar — the number of hosts currently in rollout against the host group's total member count — fetched once per ring after the ring list itself loads, rather than blocking the page. Pause and Resume toggle the ring's paused flag directly.
A failure threshold percentage is also stored per ring, and a pure evaluator (EvaluateFailureThreshold) computes whether a ring's reported failure rate has crossed it — zero reports never trips it, since there is nothing to judge yet. As with the target-percentage enforcement above, this evaluator is real and tested in isolation; whether it is wired to anything that automatically pauses a live rollout is part of the same not-yet-enforced gap.
"Adjust…" is delete-then-recreate, not an in-place update
Remove deletes a ring outright. Once removed, hosts in that group stop being scoped to a staged percentage at all, and sensor-update resolution for them falls back to the tenant-wide channel described in The sensor update channel and staged rollout.
Who can manage this
Reading rings needs xdr:rings.read; creating, adjusting, pausing, resuming and removing one needs xdr:rings.write.
What to read next
- The sensor update channel and staged rollout — the tenant-wide mechanism a ring sits alongside rather than replaces.
- Keeping the sensor up to date — the manual upgrade procedure that still governs every real rollout today.
- Sensor 1.6.0: install and verification — what you are actually installing when you run an upgrade batch.