Have each device poll on a fixed base interval, lengthen the wait after every failed attempt up to a cap, and return to the base interval after a success. Add random jitter so a large fleet does not check in at the same instant. Pick the base interval from how fast you must reach devices and what your servers can carry.
A worked example from RAUC
The RAUC update framework documents a polling feature that lets a device periodically check a URL for a bundle manifest. If it cannot fetch a valid manifest, it increases the polling interval to avoid an overload scenario. Each consecutive failure extends the base interval by the length of the base interval, and the interval never goes beyond a maximum that defaults to four times the base interval. In RAUC's example, a four hour base interval and a 24 hour maximum mean that after each failure the wait grows by four hours until it hits 24, and after one success it drops back to four.
RAUC marks polling as a preview feature that you should not yet rely on for products, so treat this as a pattern to learn from and check the current documentation before using it.
Choosing the numbers
| Factor | Pushes interval shorter | Pushes interval longer |
|---|---|---|
| Need to reach devices fast | Yes | |
| Metered or battery powered | Yes | |
| Server capacity | Yes if tight | |
| Fleet size | Yes if very large |
Also keep an out of band path for emergencies, such as a push channel or a flag in an existing connection, so a critical fix does not wait for the next poll.
Steps
- Set a base interval that matches your urgency tier.
- Cap the backoff, so a device that was offline for a day still checks in within a known time.
- Add jitter: a random offset so devices spread out. This matters most after a power outage, when thousands of devices reconnect together.
- Reset to the base interval on success.
- Make the manifest cheap to fetch. A small signed metadata file is better than a full image listing.
- Report the last successful poll time in the device record.
What the last field gives you
Last successful poll time is a good fleet health signal. A device that has not polled in several multiples of the cap is offline or broken, and belongs on a separate follow up list. Without it, your coverage numbers silently include devices you cannot reach.
Safeguard works on the vulnerability side of this: once you know a release is affected, you decide how quickly to push it, and the polling design decides how quickly devices hear about it. Try gold.safeguard.sh/scan on an SBOM for a first look.
Mistakes to avoid
The classic one is a fixed schedule that every device starts at boot. After a regional power cut, thousands of units wake together and flood the server, then fail, then retry together. Another is a retry loop with no cap, which drains batteries on a device with a dead link. A third is polling a heavy endpoint. Keep the check cheap, cap the retries, and test what happens when a hundred thousand simulated devices reconnect in the same minute.
Quick check
Why add jitter if I already use backoff?
Backoff reacts to failures. Jitter prevents the synchronized spike that causes them.
Can polling alone handle a zero day?
Only as fast as the interval allows. Keep an emergency channel for urgent fixes.
Sources
Last reviewed: 19 October 2026.
