Appearance
Backend PR 470 provides Grafana 13.2.3, Loki 3.7.8 and Alloy 1.20.1, the operations dashboard and the installation/access/retention/rollback runbook in docs/OBSERVABILITY.md. Installed on the existing VPS with explicit authorization on 2026-10-13.
Loopback-only access through SSH, authenticated Grafana, seven-day Loki retention, resource ceilings and bounded logs for the new components. A root-owned minute timer exports only the API log inode and samples eleven application/infra services. Alloy receives no Docker control socket, container metadata or database credentials. It rebuilds API JSON using approved operational fields; raw messages, URLs, headers, request bodies and account fields are not forwarded. Non-JSON provider and Python logs remain out of scope; service-health snapshots are still visible.
Validation: 1,131 API tests, TypeScript build, real Compose/Loki/Alloy validation, three readiness checks, live API/health ingestion, authenticated dashboard and datasource checks, unauthenticated dashboard rejection, loopback sockets and a synthetic privacy fixture all passed. API health/readiness stayed OK; no API, scan engine or database restart, migration, public ingress change or catalogue scheduler startup. Observed steady startup memory was about 315 MiB total.
Limitations: detailed quota/access events still require deploying already-merged backend PR 468. Aggregate API p95 is shown, not scan-specific p95. Source API Docker logs still need rotation during the next authorized API deployment. Seven-day expiry cannot be observed on installation day; retention is not a disk-size cap. Best-effort collection is not an audit trail during rotation. The existing admin-gateway unhealthy healthcheck is documented separately.
The operator chose an email alert recipient, configured privately in Grafana. SMTP delivery is not configured on the VPS: no outbound notification is claimed. Prometheus/host metrics, alert rules, provider-stage instrumentation, tracing and an external uptime checker remain follow-ups. Same-VPS monitoring cannot reliably report that entire host's failure. These PRs are not automatically merged.