Operate the control plane with evidence

Operational baseline

• Probe /health from outside the host and alert on non-200 responses.
• Collect authenticated /metrics without exposing it to the public internet.
• Alert on disk capacity, PostgreSQL availability and repeated process restarts.
• Keep JSON logs, but never add authorization headers or request bodies upstream.

curl -fsS https://devices.example.com/health
# {"ok":true,"schemaVersion":"0.1"}

Signals to watch

Product analytics is not service monitoring. Use Prometheus for service health, the account audit ledger for authorized actions and optional analytics only for coarse adoption signals.

Back up and prove restore

docker compose --env-file .env -f deploy/compose.yaml exec -T postgres \
  pg_dump -U adc -d adc -Fc > adc-backup.dump

docker compose --env-file .env -f deploy/compose.yaml exec -T postgres \
  pg_restore --list < adc-backup.dump

docker compose --env-file .env -f deploy/compose.yaml exec -T postgres \
  createdb -U adc adc_restore_check
docker compose --env-file .env -f deploy/compose.yaml exec -T postgres \
  pg_restore -U adc -d adc_restore_check --exit-on-error < adc-backup.dump

Store the dump and .env in an encrypted location with separate access controls. Verify row counts and sign-in, grants and audit against an isolated application before accepting the backup.

Upgrade procedure

1. Record the running source revision or image digest and create a verified database backup.
2. Build the new image and recreate the control plane. Database migrations acquire advisory locks before HTTP starts.
3. Verify /health, sign-in, device presence, the wake connection metric and one permitted read.
4. Retain the previous image and backup until verification is complete. A schema rollback may require restoring the pre-upgrade database.

First response by symptom