A polled device (an SNMP agent, a camera, a recorder) does not send anything by itself. The platform’s poller reads it on a schedule. This page explains the schedule, what happens on failure and what each poll costs.
The poll interval
The interval comes from the device’s profile: its Expected interval (expectedIntervalS).
| Case | Interval |
|---|---|
| The profile has an expected interval | That interval |
| The profile has none | 5 minutes (300 s) |
| Bounds | Never shorter than 30 s and never longer than 1 day (86,400 s); a profile accepts 60 to 604,800 s |
| Built-in SNMP templates | 60 s (300 s for printers) |
| Ready camera and recorder profile | 300 s |
Polled profiles use the Last seen only online rule, and the profile page shows the Expected interval (seconds) field only for the Recent message rule. A polled profile you create yourself therefore polls every 5 minutes unless you set expectedIntervalS through the API; see Devices and profiles API.
Devices of one endpoint and one profile are polled together, in one session with the box. Endpoints are spread over their interval, so not every device is polled at the same second, and the spread survives a restart.
One call at a time per endpoint
- One endpoint is polled by one call at a time, across the whole platform.
- A call has a time budget (15 s by default). For SNMP, each request also has the profile’s own Timeout (ms) and Retries.
- A limited number of your organisation’s endpoints are polled at the same moment; others wait their turn. This keeps one organisation from slowing the others.
When a poll fails
A failed poll counts against the device. The next poll waits longer each time:
| Failures in a row | Wait before the next poll |
|---|---|
| 1 | One interval |
| 2 | Two intervals |
| 3 | Four intervals |
| 4 | Eight intervals |
| … | Doubled each time, at most 1 hour (and never less than one interval) |
A small random spread (±10 %) keeps a whole site that failed together from retrying at the same second.
After 3 failed polls in a row the device counts as offline once: Hermetry writes one inactivity message for it, which an offline alarm rule can act on (see Offline alarms). The device’s Connection tab shows “The device has not answered since …”, Failed polls in a row and Last error.
The first successful poll clears the count and the device is polled at its normal interval again.
A switched-off endpoint is not polled at all. An endpoint saved after a failed test is switched off until you switch it on; see Protocol endpoints.
How polls count toward your quota
| What is written | Messages |
|---|---|
| The readings of one device from one poll | 1 message |
| The device’s attributes from a poll | 1 more message, only when they changed since the last poll |
| The offline mark after 3 failures | 1 message |
| One device event (cameras and recorders) | 1 message per event envelope; a burst folded into one envelope counts once |
A poll result over your plan’s message limits is dropped and counted, never queued for later. See Message quota and usage.
Example. A UPS polled every 60 s writes 1,440 telemetry messages a day, plus a few attribute messages when its identity or rated values change. A switch on the same interval costs the same: one message per poll, however many interfaces it reports. The number of keys in a poll counts toward your data-point limits, and a mapping is capped at 200 telemetry keys per device.
Choosing an interval
- Status that alarms depend on (UPS on battery, a link down): 60 s.
- Slowly changing values (printer supplies, disk usage): 300 s or more.
- Remember that a counter rate needs two polls, so the first rate appears one interval after the device is added or the poller restarts.