Normal, Watch and Alert — cloud alarms for every reading

Updated 30 Sep 2026

Every reading on a tag that has an alarm limit is one of three levels:

Only Alert is an alarm. Watch is the early warning that lets you act before a reading becomes one.

Rollout. Cloud alarms are being rolled out account by account and need a plan that includes alert thresholds. If you don't see a Watch value when editing a limit, no Alarms evaluated setting on a device, or no Active alarms entry in the sidebar, contact support.

Set the limit and the Watch value

1. Open the device and find the tag.
2. Edit its alarm limit. Pick a mode — Alarm above, Alarm below, Alarm outside a range, or Alarm beyond ± — and type the limit.
3. Optionally add a Watch value in the same mode. It has to sit strictly inside the limit; for a range, either side is optional.
4. Optionally set a hysteresis (below).
5. Save.

Enter limits in the tag's engineering units — the value as it appears on your dashboards, after the tag's scale factor and offset (see device parameters). That is what the reading is compared against, whether the gateway or the cloud does the comparing.

A lake water-quality station, for example:

A Dissolved Oxygen reading of 4.6 mg/L is Watch; 3.8 mg/L is Alert; 5.4 mg/L is Normal. A pH of 8.3 is Watch (past the upper watch value of 8.2), and 8.6 is Alert.

Hysteresis — stop a reading flapping on the limit

A value that hovers on its limit — 3.98, 4.02, 3.99 — would otherwise alarm and clear over and over. Hysteresis is how far back inside a limit a reading must come before it leaves Alert (or Watch), in the tag's units.

With Dissolved Oxygen set to alarm below 4 mg/L and a hysteresis of 0.3:

• 3.9 → Alert (entering is immediate),
• 4.1 → still Alert (it hasn't come back 0.3 above the limit),
• 4.3 or more → back to Normal, and a Threshold cleared event.

Hysteresis only slows the way down a level. Going up — Normal to Watch, Watch to Alert — always happens on the first reading past the value. It applies to the Watch value in the same way.

On a device whose alarms are evaluated on the gateway, the gateway clears the alarm itself, with no hysteresis, so hysteresis there applies to Watch only. Evaluated in the cloud, it applies to both.

Where the alarm is evaluated

Synacl's ESP32 gateway firmware has always compared readings against their limits itself, so it alarms even while its uplink is down. Nothing else does: a device Synacl polls, a webhook device, a direct MQTT device, or a device behind a gateway that isn't a Synacl ESP32 has no firmware to raise an alarm. Synacl now evaluates those in the cloud, on every reading that arrives.

Each device has an Alarms evaluated setting on its page:

Exactly one side raises a device's alarms. A device evaluated in the cloud does not carry its limits in the gateway's configuration, so:

• Switching a gateway device between the two moves its limits into or out of the gateway's configuration, and the gateway restarts once (under a minute — the same restart as any configuration change). Do it when the device is not mid-job.
• After that, editing a cloud-evaluated device's limits never restarts the gateway. It also doesn't take up room in the gateway's configuration — see how many devices and tags one gateway can hold.
• Changing this setting needs the Change parameters permission.

On the gateway: the gateway raises the alarm locally, at its read interval, online or offline. The cloud still tracks the level for the badges and Active alarms page, and adds Watch — which the firmware doesn't know about, so Watch needs the readings to reach Synacl.

In the cloud: the reading is graded when it reaches Synacl, so alarms react at the device's publish interval rather than its read interval. Nothing is evaluated while the device's gateway is offline, and readings a gateway buffered while offline are replayed into your charts without raising alarms, like everything else in a replay.

Alarm events and notifications

For a device evaluated on the gateway, the gateway raises Threshold violation and Threshold cleared itself, exactly as before; the cloud adds the Watch event. Leaving Watch back to Normal only updates the level — no event.

They appear in the events feed and follow your notification preferences and quiet hours as usual: neither Error nor Warning breaks quiet hours — only Critical does. Alarms fire on the crossing, once in and once out, never on every reading. Watch is not counted as an alarm in job reports.

The levels don't send email, call a webhook or run anything. For that, create an alerting rule on the tag — rules add delivery, severity and cooldown, and a rule's threshold is separate from the tag's alarm limit.

The Active alarms page

Active alarms in the sidebar lists every tag that is currently on Watch or in Alert across your account — alerts first, then the longest-standing — with its current value, its limit in words (Alarms below 4 mg/L), and since when. It updates live, so it is the page to leave open on a wall screen.

Around it:

• The Devices list and each device's page show a Normal / Watch / Alert badge.
• The Connectivity summary widget counts devices on Watch or in Alert under need attention.
• The Progress bar and Level meter widgets can draw the limits — see threshold markers.

Seeing Active alarms needs view access to devices. A device that is offline or unreachable isn't graded — it has nothing to grade — so it drops off the page until it reports again; its status dot still says why (see device status).

Related

• Alert thresholds (and the yellow dot)
• Device parameters (tags)
• Create an alerting rule
• Event types reference