System

The System page is the operator's housekeeping module: profiles, snapshots, and diagnostics (the page header). It is where you pick a colour theme, save and swap whole rig configurations, save and swap just the device assignments, and grab the one-click bundle you send when something goes wrong. It is intentionally small — four cards, no live telemetry, no version/uptime/resource/thread readouts.

It is not the self-healing engine. The watchdog that watches memory, disk, threads and hung devices and can escalate to a safe-state is the Health monitor, a separate background daemon — see that topic. The cards here are Appearance (theme), Equipment profiles (devices only), Configuration snapshots (whole config), and Diagnostics (the debug bundle download).

Appearance

Pick the colour theme for the web UI. Themes are saved per browser (in local storage) and applied instantly — no restart, so a change here never touches your config file and never affects another machine viewing the same rig.

• Original — dark blue, the default.
• Light — bright, for daytime work.
• Red — night — shades of red on black to preserve dark adaptation at the eyepiece.
• High contrast — maximum legibility.

Equipment profiles

Saves only the equipment — the ASCOM + Alpaca driver assignments — plus the focuser's mechanical characterisation (measured/approved backlash and the characterisation report). Nothing else travels with a profile: it deliberately leaves out the focuser's operational and safety prefs (direction reversal, travel limits, jog step), so applying a profile can never silently revert those. Use one to swap cameras / mounts / focusers etc. without changing any of your other settings. The active profile (tracked in a .active_equipment_profile marker) shows as · active in the list.

• Save current devices — stores the current device block. Lists at GET /api/equipment_profiles; saves at POST /api/equipment_profiles/save.
• Apply & restart — merges the saved device block back into the live config, persists it, and restarts Starship so the transports re-initialise; everything outside the device blocks is left exactly as it is. POST /api/equipment_profiles/apply.
• delete — POST /api/equipment_profiles/delete.

Configuration snapshots

A snapshot is the whole configuration — devices and every setting. Save the current setup, or load one to switch entire rigs. To swap only the devices, use Equipment profiles instead — loading a snapshot replaces all of your settings.

• Save current as snapshot — POST /api/profiles/save; the list comes from GET /api/profiles.
• Load & restart — overwrites the current config with the snapshot and restarts Starship so transports re-initialise. The UI confirms first. POST /api/profiles/load.
• delete — POST /api/profiles/delete.

Diagnostics

A one-click ZIP bundle for remote debugging. Download diagnostics links straight to GET /api/diagnostics, which streams starship-diag-<timestamp>.zip. The bundle is built best-effort in memory (starship/core/diag.py): a failing section becomes an .error.txt note rather than failing the whole download. It contains the recent log (ring buffer, see below), the active config.toml, recent console job history (last 200), the audit-log tail (last 300 events), the ASCOM/Alpaca slot assignments, the health monitor's memory snapshot, and Python/platform info.

When you hit a problem, download this immediately after the failure and attach the zip — it is the fastest way to get a fix.

The recent-log ring buffer

Starship logs to the console only, so without a capture the bundle's recent log would be empty. A small in-memory ring buffer ([diag]) keeps the most recent lines so they ride along in the bundle. ring_buffer_size (default 2000) sets how many formatted log lines to retain — lower it on a RAM-tight host (e.g. a LattePanda); max_log_line_length (default 0 = no limit) truncates any single line.

Restart and shutdown — note where they live

The System page itself has no restart or shutdown button — the only thing on it that restarts Starship is applying an equipment profile or loading a snapshot. The general controls live elsewhere:

• Restart — Settings' Save & restart posts to POST /api/config/restart, which reloads the config and re-initialises modules.
• Terminate (shutdown) — the topbar Terminate button posts to POST /api/system/terminate; you must type SHUTDOWN to confirm. It is guarded by what is actually happening, not the sky verdict (the sky is normally UNSAFE in daytime, which says nothing about stopping the software): it refuses while a blockscript session is active or any job is in progress (capture / slew / roof motion). The roof is held by the hardwired CloudWatcher interlock regardless.

Relationship to the Health monitor

Keep the two straight: this page is the operator UI for profiles, snapshots and the diagnostics download, while the Health monitor is the background self-healing daemon whose live state is served at GET /api/health/status, not here. They meet only in the diagnostics bundle, which includes the health monitor's memory snapshot. See the Settings, Equipment, Audit, and Health monitor topics.