Sizing your publish rate
To stay under your limits, work backwards from your fleet:
- Per device: pick a publish interval ≥ your plan's minimum. Most monitoring (temperature, energy, tank level) is fine at 0.1–1 Hz. Reserve faster rates for genuinely fast signals.
- Aggregate: estimate
devices × messages-per-second. Keep it under your plan's aggregate cap. Example: 50 devices each every 5 s = 10 msg/s. - Headroom: leave ~20% slack for bursts.
If the math exceeds your tier, either slow the interval, batch multiple readings into one message, or upgrade your plan. The Quota & limits page shows your real numbers and current usage. Background: understanding rate limits.
The real minimum is not just your plan
Your plan sets a floor on publish rate, but the transport sets one too, and the larger of the two wins. The Add Device and Edit Device forms show the effective minimum in the field's tooltip.
| Device | Smallest publish interval |
|---|---|
| Connected through a gateway | 10 seconds. The gateway's polling loop runs on a 10-second cycle, so a lower value still publishes every 10 seconds. |
| Polled by Synacl directly (HTTP, SNMP, gateway-less Modbus TCP) | 1 second. Below this the poller skips the device entirely and it sends nothing at all. |
Publishing faster than your plan allows is not an error — the extra messages are simply dropped on arrival, and repeated violations escalate. See what suspension means.
Publishing slowly does not mean reacting slowly
For devices on a gateway, how often you publish is separate from how often the gateway reads. Threshold alerts and macros that run on the gateway fire from the read, so you can report to the cloud once a minute while still catching a fault within ten seconds. Set Read Interval on the device to control that; leave it fast and raise the publish interval to save quota.