Running Sentinel

Day-to-day operations: monitoring, backups, upgrades, scaling and data retention.

Health and monitoring

• GET /healthz: the process is up.
• GET /readyz: the database is reachable and migrations are current (503 otherwise). Use it for load balancer checks.
• Console Settings → System: version, nodes and their last check-in, job queue (queued, running, failed, dead), database and migration version, live console clients.
• Logs are structured (JSON) with request_id, route, status and duration_ms. They never contain clipboard content, masked matches, evidence, passwords, codes, tokens or keys.

Backups and restore

• Back up PostgreSQL with your usual tooling (pg_dump, snapshots, point-in-time recovery). All Sentinel data, including encrypted media, is in the database.
• Back up the key file separately and offline. A database backup is useless without the key file that was current when it was taken.
• Restore: restore the database, put the matching key file in place, start Sentinel. Devices resynchronise automatically.

Upgrades

1. Read the release notes and back up the database.
2. Stop the service, replace the binary, start the service. Migrations run at start; with several nodes, one node migrates while the others wait.
3. Migrations are forward-only. To roll back, restore the backup and the previous binary.

High availability

Run two or more nodes with the same configuration and key file behind a load balancer. Sessions, live updates, background jobs and rate limits are coordinated through PostgreSQL. PostgreSQL high availability is provided by your platform (managed service, Patroni or similar).

Retention

Configure retention in Settings → Retention (defaults: findings 365 days, alerts 730 days, audit log 7 years, evidence requests 30 days, integration deliveries 30 days). A daily job removes expired data; audit log retention keeps the chain verifiable by recording an anchor.