Alert catalog
What every notification means
A reference of the notification subjects you might see from OpenSense and what each one means. Sorted by severity then by frequency.
Channel-state alerts
🔴 ALARM — <channel> at <value> (range <ok_min>–<ok_max>)
The channel has been out of operating range for longer than the grace period. This is the load-bearing notification.
What to do:
- Open the dashboard via the link in the message.
- Inspect the chart for the last hour: is the value still out of range, or did it bounce back?
- If still out: investigate the physical world. Door open? Equipment failure? Power outage?
- Acknowledge the event with a note.
Don't:
- Soften the threshold to make the alarm go away. That treats the symptom, not the cause.
🟡 WARN — <channel> at <value> (entering grace)
The channel just left the operating range. The grace period is counting down; if it returns to range before grace expires, no alarm fires.
What to do:
- Often nothing; this is informational. If you see WARN frequently with no ALARM, your grace period is well-tuned.
🟢 OK — <channel> cleared
The channel returned to range. If an ALARM had fired, this also
emits alarm_cleared in the audit trail.
What to do:
- Add a clearing note explaining the cause if known. "Door closed by night manager at 22:45." The audit trail is more valuable with notes.
⚫ SILENCED — <channel> alarm during silence window
An alarm condition occurred during a configured silence window. No notification was emitted (this one is the digest summary); the audit log records the event.
What to do:
- Confirm the silence window is correct. If alarms fire during silence frequently, you may have a misconfigured window or an underlying problem the silence is masking.
Device-state alerts
📡 OFFLINE — <device> no data for <Δt>
The device has not reported in > 2 × cadence. See
device-offline.
📡 ONLINE — <device> reconnected
The device started reporting again. If readings were buffered (some ESP32 firmware, all LoRaWAN), the gap may fill in retroactively.
🔋 BATTERY LOW — <device> at <pct/V>
Battery dropped below 20 % (Gen1) or 3.4 V (Gen3).
What to do:
- Replace the battery within a week.
- For LoRaWAN, the device will run for ~1 month after this notice before going offline.
🔋 BATTERY CRITICAL — <device> at <pct/V>
Battery below 5 % or 3.1 V. Replace today.
Configuration alerts
🔑 TOKEN ROTATED — <device>
An ingest token was rotated. Sent to the account holder; not to operators.
🔑 TOKEN AGED — <device> token > 365 d
Reminder that the token has not been rotated in a year. Advisory, not enforced.
🛠 RULE CHANGED — <channel>
A rule's threshold was edited. Sent to the audit log; sent as a notification only if the account has subscribed to configuration events.
🔇 SILENCE STARTED / ENDED — <channel>
A silence window opened or closed. Informational; included in the account-level digest.
Account-state alerts
💳 INVOICE — paid
💳 INVOICE — failed
💳 TRIAL ENDING — <days> left
💳 ACCOUNT PAUSED
💳 ACCOUNT DELETION SCHEDULED — <date>
Billing lifecycle. Sent to the account email only.
System alerts
⚙ INGEST DEGRADED — <region>
Our ingest path is slow. Sent only if degradation lasts > 5 min.
⚙ INGEST DOWN — <region>
Our ingest path is unreachable. Sent only if > 1 min. We send from infrastructure independent of the ingest path; this notification survives our own outages.
⚙ MAINTENANCE — scheduled <date>
Planned maintenance window. Sent 7 days in advance.
Operator alerts (if Telegram bot is in a group)
The bot may also reply to commands in groups:
/ack <event_id>→ acknowledges the event with the sender as the acknowledger./silence <channel> <minutes>→ opens a silence window./status <channel>→ posts the current state and last 5 readings.
These commands log to the audit trail same as if done in the dashboard.
What we do not emit
- Marketing emails. Ever.
- "Your data is healthy, no action required" pings. (We deliberately do not send these. Silence is success.)
- "Tips & tricks" suggestions. (The docs are the docs; we will not ping you to "discover" them.)