Alerts

The Alerts page sends you outbound notifications when something important happens at the observatory — a sequence finishes or fails, the sky becomes unsafe, or the safety monitor reports an error. It's how you find out about events without watching the UI. The AlertsManager subscribes to the event bus and, when an enabled condition fires, sends a message on every channel you've turned on.

There are two channels: email (over SMTP) and Pushover (over its HTTPS API). You can enable either, both, or neither. A single master switch (enabled) governs the whole feature — when it's off, nothing is ever sent, regardless of channel or condition settings.

The routing — which event maps to which condition and message — is unit-tested. The sending is real network I/O (smtplib for email, an HTTPS POST for Pushover) and can only be confirmed against your own SMTP server / Pushover account. Every send is wrapped so a failure is logged and never propagates back into the event bus.

Email (SMTP)

Tick on for email (email_enabled) and fill in your provider's SMTP details:

• smtp_host — e.g. smtp.gmail.com
• smtp_port — default 587
• smtp_user / smtp_password — your SMTP credentials. The password is write-only: it is never sent back to the browser, and saving with the password field blank keeps the stored one.
• smtp_tls — use STARTTLS (default on)
• email_from — the From address
• email_to — comma-separated list of recipients

Email is only sent if smtp_host, email_from, and email_to are all set. If smtp_user is blank, the send skips the login step (for relays that don't require auth).

Pushover

Tick on for Pushover (pushover_enabled) and paste two values from your Pushover dashboard:

• pushover_user_key — your user key
• pushover_app_token — your application/API token

Both are required. Failed sequences, stopped sequences, unsafe transitions and safety-monitor errors are sent at Pushover priority 1 (high); the routine ones (sequence complete, safe again) go at priority 0.

Which events fire an alert

Each condition is an independent toggle. The defaults are chosen so you hear about the things that matter and aren't spammed by routine ones:

• on_sequence_complete (default on) — a sequence finished successfully
• on_sequence_failed (default on) — a sequence ended in a FAILED state (high priority)
• on_sequence_stopped (default on) — a sequence was stopped or halted, e.g. a meridian halt or a flip failure (high priority — a silent stop can quietly cost you the rest of the night)
• on_unsafe (default on) — the safety state changed to UNSAFE (high priority)
• on_safe (default off) — the safety state returned to SAFE
• on_safety_error (default off) — the safety monitor reported an error or stale data (high priority)

The sequence conditions are driven by sequencer.state events; the safety conditions by safety.state_changed; and the safety-error condition by solo.error / solo.stale. When a sequence fails or is stopped, the alert includes a Reason line if the underlying event carried one (for example the halt or flip-failure detail). The UNSAFE message carries the verdict's reasons; UNKNOWN safety verdicts are treated as unsafe for alerting purposes.

Send a test alert

The Send test alert button dispatches a fixed test message on every enabled channel so you can confirm the wiring end-to-end. It requires the master switch to be on. The result reports per-channel success, so you can see exactly which channel delivered and which failed and why.

Saving and when changes take effect

The Alerts page has its own Save endpoint. On save the config is written to your config.toml and the live AlertsConfig is updated in place. The AlertsManager reads the config fresh on every event, so saved changes take effect immediately — no restart needed.

Edge-firing and de-duplication

Safety alerts are edge-triggered: the manager tracks the previous safe/unsafe state and only sends on a genuine transition (safe → unsafe, or unsafe → safe), so repeated readings of the same state do not re-send. There is no time-based throttle beyond this — sequence and safety-error conditions fire once per underlying event, so a flapping condition can produce repeated messages.

Endpoints

• GET /api/alerts/config — returns the current config. The SMTP password is blanked; a smtp_password_set flag tells the UI whether one is stored.
• POST /api/alerts/config — saves the config and persists it to config.toml.
• POST /api/alerts/test — runs send_test() and returns the per-channel result.

Caveats

• Master switch first. With enabled off, no condition and no test alert sends anything.
• A channel must be on. With neither email_enabled nor pushover_enabled set, a dispatch returns no channel enabled.
• Real delivery is your account's job. The routing is tested; SMTP/Pushover delivery depends on correct credentials and a reachable server. Always run a test send after configuring.
• Send failures are silent to the night. A failed alert is logged but never interrupts the bus or the sequence — so don't treat a missing alert as proof nothing happened.

Configuration

These settings live in the [alerts] section of config.toml and mirror the page controls. See the Settings and Config file topics for how the file is loaded and saved.

Current build: v19.62.