Alerts & Notifications
Alerts tell you when something needs attention; notifications deliver those alerts outside the browser.
Alert rules
Section titled “Alert rules”Built-in rules turn events into alerts. Each rule has a severity and a debounce — the shortest gap before the same kind of alert rings the bell again. A debounced alert isn’t lost: the underlying event is still recorded on the Events page.
| Alert | Severity | Debounce | Fires when |
|---|---|---|---|
| Camera offline | warning | — | A camera has had no source for several health polls |
| Camera degraded | warning | 2 min | Reachable, but the stream is impaired — stalled frames or low/zero bitrate |
| Camera back online | info | — | A camera recovers |
| Tamper detected | warning | 2 min | A cover obstruction or view change is detected |
| Motion detected | info | 1 min | A motion event fires on a camera |
| Alta server unavailable | critical | — | An Alta server is down (sustained) or flapping |
| Alta server restored | info | — | A downed Alta server recovers |
| Alta server restarted | warning | 30 s | The Alta process restarted, proven by an instance-ID change or uptime reset |
| Alta connectivity blip | info | 30 s | A brief Alta outage recovered without the process restarting |
| Alta config drift | critical | 3 min | An Alta server’s live config no longer matches what Alta VMS expects |
| Critical event | critical | — | Any other event flagged critical |
Visibility follows the event’s scope: server- and system-scope alerts (the Alta … rows, and any system-level critical event) are admin-only. Camera-scope alerts (offline, degraded, online, tamper, motion) follow your group membership.
Live alerts
Section titled “Live alerts”New alerts arrive in real time over Server-Sent Events and appear under the bell in the top bar. Each alert points at an event — the event is the incident record, and everything you do with the alert is written to it (see Events).
An alert offers three actions:
- Acknowledge — take ownership: “I’m handling this”. Available to operators and admins. Acknowledgement is first-wins: once someone acknowledges, every bell shows Acknowledged by with that person’s name, and a later acknowledge attempt does not replace the original owner. An optional comment can be added and is recorded on the event.
- Resolve — admin-only. Closes the incident for all users at once and removes the alert from every bell. A resolution comment is required; the comment and resolution details are visible on the Events page.
- Dismiss — hides the alert for you only. Other users are unaffected, and no special permission is needed.
Select several alerts to acknowledge or dismiss them in bulk.
After a network interruption or laptop sleep, the browser reconnects and resynchronizes automatically, so alerts that fired while disconnected are not missed.
Reading a bell alert
Section titled “Reading a bell alert”Each alert row shows a severity-colored icon and bar, a title from the event type, and the affected camera (with its IP) or Alta server as a link that jumps you straight to it. Unhandled alerts carry an unread dot; once someone takes ownership the row shows Acknowledged by [name].
Expand a row with its chevron to see read-only detail from the underlying event — the reason, failure type, how a server recovery was detected (probe or instance ID), outage duration, Alta uptime, a status change shown as from → to, any error text, and the event time. Alerts with nothing more to show read No additional details.
Your alert preferences
Section titled “Your alert preferences”Under Settings → Alerts each user controls their own alert preferences — which alerts they want surfaced and how. These settings are per-user and don’t affect anyone else.
Notifications
Section titled “Notifications”Notifications deliver alerts outside the browser. They are configured under Settings → Notifications as three layers:
| Layer | Answers | Examples |
|---|---|---|
| Connection | What we send with | One SMTP server, one Web Push (VAPID) identity, one Telegram bot — one of each |
| Recipient | Where/whom it lands | An email list, Telegram chat IDs, a webhook URL, or browser push subscriptions |
| Rule | When and what | Which event types, scope, severity, and throttle — routed to one recipient |
Supported channels are Email (SMTP), Web Push (browser notifications), Telegram, and Webhook. Webhook recipients need no connection; the other channels send through their shared connection.
If a channel’s connection isn’t configured, delivery for that channel is skipped — alerts still appear in-app. To use Web Push, an admin first enables the Web Push identity, then each user subscribes their browser.
Not every alert can be routed externally: camera-degraded and the Alta server-health alerts (unavailable, restored, restarted, blip, config drift) appear in-app only and aren’t available as notification-rule triggers.
Delivery reliability
Section titled “Delivery reliability”Alerts and notifications are persisted before delivery, so they survive a service restart and load bursts. Delivery is at-least-once with de-duplication — a rare duplicate notification is possible by design.
Failed email, webhook, Telegram, and push sends are retried with backoff and abandoned only after repeated failures; abandoned deliveries appear in server logs and metrics, not in the UI. Throttling counts only confirmed deliveries — a failed send does not consume the throttle window. A hung SMTP server times out after about 30 seconds and never delays the other channels.