Alerts

What raises an alert, how to resolve alerts, and how to send them to email or a webhook

  8 minute read  

Alert Types

The management platform monitors board health and PoE port states, generating alerts when conditions need attention. The trigger values are built into the software and cannot be changed.

AlertSeverityRaised whenAlert text
CPU temperatureCriticalThe CPU is above 80°C. Re-arms at 75°C or below“Running hot (85 °C). Check airflow or fan.”
Memory usageWarningMemory use is above 90%. Re-arms at 85% or below“Memory usage high: 92%”
Root disk, warningWarningThe root disk is above 85% used or has less than 512 MB available“Storage almost full (88%, 410 MB free)”
Root disk, criticalCriticalThe root disk is above 95% used or has less than 256 MB available“Storage almost full (96%, 200 MB free)”
PoE faultWarningA port enters the fault state“PoE fault on Lobby Camera”
PoE device lostWarningA port that was delivering power stays enabled for about 10 seconds with no power drawn“PoE device lost on port 0-3 (Lobby Camera): port is still enabled but no power is being drawn…”
Service failedWarningA monitored system service enters the failed state“Service failed: ”
Uplink change undoneWarningA network change was reverted because you did not confirm it in time“Uplink eth1 auto-reverted - the change was undone because connectivity was not confirmed in time.”
Uplink revert failedCriticalThe automatic revert itself failed“Uplink eth1 auto-revert FAILED (…) - the board may be on a bad config; manual recovery may be required.”
Fleet settings differWarningA paired board has a different value for a compared setting“Fleet settings don’t match: 1 difference with 2 other boards”
Auto-restart device stuckWarningAuto-restart device power-cycled a port and the device still did not return“Auto-restart device stuck on port 0-3 (target 192.168.1.20)”

A disk alert has a Free up space drop-down on its row with the steps to take: look for superseded kernel packages and orphaned linux-raspi-headers-* packages, which are the usual cause. The health tiles on the dashboard use the same values, so a tile turns yellow or red at the point where the matching alert is raised. See System Health.

Viewing Alerts

Active alerts appear in two places:

  • Dashboard - The Active Alerts panel lists every unresolved alert with its severity, time, and message. A health tile with an open alert shows a View alert link that jumps to it.
  • Fleet view - Fleet-wide alerts appear in the fleet status bar (e.g., “3 PoE faults across 2 boards”)

Each alert row shows:

  • Severity - Warning or critical
  • Time - When the condition was first detected
  • Message - Plain-English description, including port labels where applicable
  • Delivery badge - Whether the alert was sent by email or webhook (see Alert Delivery)

Resolving Alerts

Once you have addressed the underlying issue:

  1. Find the alert in the Active Alerts panel
  2. Click Resolve to mark it as addressed, or Resolve all to clear every open alert

The board does not resolve CPU, memory, or disk alerts by itself when the reading recovers, so a tile keeps the alert’s color until you resolve the alert.

Resolved alerts are removed from the active view but remain in the audit log for historical reference.

Auto-Restart Device (Automatic Recovery)

Auto-restart device turns the 11pm “a camera locked up again” phone call into something that fixes itself. It continuously probes a device on a PoE port and, if the device stops responding, power-cycles the port to recover it - unattended. The operator sees what happened the next morning in the activity log, instead of getting paged overnight.

How It Works

Auto-restart device pings (or TCP-connects to) a target you configure on a 10-second cadence. After a number of consecutive failures (default 3), it automatically cycles the port’s PoE to reboot the attached device. If the device still does not come back after the cycle, the port is marked stuck, cycling stops, and an alert is raised for a human to look at.

Setting It Up

  1. Find the Auto-restart device row on any PoE port card (the same row is at the top of the port’s History window) and click Set up. Once it is set up, the button says Edit.
  2. Set the target IP or hostname - usually the camera, access point, or NVR on that port.
  3. Optionally set TCP fallback ports - it connects over TCP if the device’s firewall blocks ICMP ping.
  4. Adjust the timing if needed. Defaults are tuned per board type (Cruiser uses a 5-second post-cycle dwell; Interceptor uses 15 seconds for its slower switch driver).
  5. Click Save. The next 10-second tick picks up the change - no restart needed.

State Badges

The Auto-restart device row on each port card shows one status:

  • Off - not set up, or set up but turned off.
  • On - actively checking the device.
  • Restarting - the port was just power-cycled and it is waiting for the device to come back.
  • Paused - the port was turned off by an operator; auto-restart waits until it is turned back on.
  • Stuck - cycled once, device still down, manual intervention required. It also shows as a red pulsing Stuck badge at the top of the card.

The Auto-restart devices section of the dashboard lists every port on the board that has it set up, with the same statuses.

The Stuck Alert and Re-Arm

When Auto-restart device declares a port stuck, a warning alert lands in the Active Alerts panel with an inline Re-arm button. Clicking it re-arms Auto-restart device and resolves the alert in one action. A manual power-cycle (the port card’s Reset button) does not re-arm it - only the explicit Re-arm action does. In a fleet, stuck ports also bubble up to the fleet-wide alerts banner so a single row summarizes stuck ports across all boards.

The dashboard and alert emails say “Auto-restart device stuck on port …”. The webhook message field keeps its original wording, so Home Assistant automations that match on it keep working.

Storm Protection

A cooldown floor (default 300 seconds, minimum 30) sets the minimum time between cycles on a port, counted across every source - operator clicks, group resets, and Auto-restart device cycles all count toward it. This prevents thrashing on a flaky device.

Forensics

Every Auto-restart device action is recorded: cycles, stuck transitions, recoveries, and operator re-arms each write an audit-log entry, and the per-port cycle history shows the full timeline.

Alert Delivery (Email and Webhook)

By default, alerts live in the dashboard. Alert delivery pushes them out to your phone or chat tool. Auto-restart device stuck alerts carry a one-tap Cycle port now link. The integrator’s overnight workflow becomes: alert arrives on the phone, tap the link, the dashboard opens with the right port already focused, tap Reset. Two taps, end to end.

Configuring Delivery

  1. Open Alerts from the ⋮ more menu in the header.
  2. Set the deep-link base URL - the public URL operators use to reach this board’s dashboard.
  3. Fill in the SMTP tab (email) and/or the Webhook tab (the board POSTs a JSON alert to a URL you provide; Home Assistant webhooks and n8n can take it directly, while Slack and PagerDuty need a small relay that reshapes the JSON), then click Save to apply that tab’s settings.
  4. Use Send Test to do a dry run - it dials your SMTP server or POSTs to your webhook with the on-screen draft, without touching the stored config or the running watcher. You do not need to enable delivery first to test it.

Saving a real change reconfigures the running alert watcher atomically - no restart required.

The “Cycle port now” link is captured before login runs, so a login redirect cannot lose it; the dashboard then scrolls the matching port card into view and focuses its Reset button. On a successful cycle, the open stuck alert for that port is resolved automatically.

Pending deliveries are retried on a 1-minute, 5-minute, then 15-minute backoff before being marked failed (the alert itself stays active until resolved). Each alert row shows a small delivery badge: delivered, queued, delivering, delivery failed, skipped, or not sent (raised before delivery was set up; alerts raised earlier are not re-sent once you configure delivery).

Alert Storage

Alerts are stored persistently in the board’s SQLite database. They survive reboots and are included in backup exports. Alert history is available via the audit log.

API Access

Active alerts are available via the REST API:

# List active alerts
curl -k -H "Authorization: Bearer <token>" \
  https://<board-ip>/api/v1/system/alerts/active

# Resolve an alert
curl -k -X POST -H "Authorization: Bearer <token>" \
  https://<board-ip>/api/v1/system/alerts/1/resolve

Last modified October 18, 2026