Telemetry and Kill Switches

Odeion collects performance metrics about itself and the host it runs on, and exposes a set of kill switches for disabling features at runtime. Both live under Admin > Settings > Operations.

What Telemetry Collects

Four collector groups can be toggled independently. All are enabled by default.

Setting	Default	Collects
telemetry_system_enabled	true	Host CPU, memory, disk, and network usage.
telemetry_process_enabled	true	Goroutines, RSS memory, and file descriptors for the Odeion process.
telemetry_application_enabled	true	Transcode sessions, HTTP request rates, and background task throughput. Powers most admin dashboards.
telemetry_postgres_enabled	true	Connection counts, transactions, cache hit ratio, table and statement stats. The heaviest group; turn it off if you never look at the database panel.

Metrics are charted in the admin panel under Admin > Telemetry.

Data Locality

All telemetry is stored in your server’s own PostgreSQL database and never leaves your server. Nothing is reported to Odeion’s developers or any third party. The only way metrics leave the machine is if you export them yourself, for example inside a diagnostic bundle you choose to share.

Retention and Rollups

Raw samples are downsampled into rollups over time. Each tier has its own retention setting:

Setting	Default	Keeps
telemetry_retention_raw_hours	6	Raw-resolution samples, in hours.
telemetry_retention_1min_hours	24	1-minute rollups, in hours.
telemetry_retention_1hour_days	90	1-hour rollups, in days.
telemetry_retention_1day_days	365	1-day rollups, in days.
telemetry_max_storage_size_mb	0	Cap on total telemetry storage in MB. 0 means uncapped.

Changing Telemetry Settings

Edit them in Admin > Settings > Operations, or in bulk with odeion config edit under the telemetry section. Changes take effect without a restart.

Kill Switches

Kill switches disable a server capability instantly, without a restart and without touching the underlying configuration. They are meant as emergency brakes: pausing scans during a disk migration, stopping logins during an incident, or shutting down playback while you debug a transcoder problem.

Setting	Effect when enabled
killswitch_playback	Blocks all streaming and transcoding. Active sessions are terminated.
killswitch_downloads	Blocks direct file downloads and download-mode transcodes.
killswitch_login	Blocks new sign-ins. Existing sessions keep working.
killswitch_registration	Blocks new account creation, even with a valid invite code.
killswitch_tasks	Pauses the background task dispatcher. In-flight tasks finish; queued tasks wait.
killswitch_scanning	Blocks manual and scheduled library scans.
killswitch_oauth	Blocks sign-ins through OAuth providers. Password logins are unaffected.
killswitch_api_keys	Rejects API key authentication for all users, including admins. Session and OAuth logins are unaffected.
killswitch_webhooks	Pauses outbound webhook deliveries. Events that occur while paused are not sent later.

Every switch has a toggle in Admin > Settings > Operations. Saving kill switch changes asks for confirmation and lists exactly which features will be blocked or restored. While any switch is active, a warning banner is shown across the admin panel.

Clients degrade gracefully while a switch is on: the web player shows a “temporarily disabled” notice instead of a playback error, download options are hidden, and the login and registration pages explain that sign-in is unavailable rather than failing on submit.

Disabling a kill switch restores the feature immediately. Nothing is lost while a switch is on (webhook deliveries excepted, see above): queued tasks resume, and locked-out users can sign in again.