Skip to content

System status

Administration › Maintenance › System Status is the live health page for the web-portal host and its backing services. Check it first when the portal is slow, storage is filling up, or background processing lags.

What the page shows

  • System — OS version, hostname, system uptime, CPU count, and memory usage (with a usage bar).
  • Storage — a per-device table: device, file path, file system, disk size, used space, and a disk-usage gauge. Watch the volume that holds the recordings directory.
  • Database — PostgreSQL version, database uptime, total size, and the ten largest tables with approximate row counts. A View database metrics link opens the detailed database status pages — per-statement and per-connection views for diagnosing slow queries and connection pile-ups.
  • PGBouncer — the connection pooler's version, or "Not detected" when PGBouncer is not in front of the database. A dedicated PGBouncer status page shows pool details when it is present.
  • Redis — version, uptime, current and peak memory usage, and connected clients.
  • Task manager — the Tasks in queue count of Celery tasks currently waiting. A persistently growing number means background processing (dashboards, reports, jobs) is falling behind.

Health-check endpoints

For external monitoring, the web portal exposes unauthenticated HTTP endpoints:

Endpoint Purpose
/health and /health/ready Readiness: checks PostgreSQL and Redis connectivity; returns HTTP 200 with {"status": "ok", "postgresql": "...", "redis": "..."} when both pass, HTTP 503 otherwise.
/health/live Liveness: confirms the web process itself is responding.

Requests to /health and /health/ready are rate-limited (HTTP 429 when exceeded), so poll them at a moderate interval; /health/live is not rate-limited and is safe for frequent liveness probes.

  • System log — the error log to check when a gauge here looks wrong.
  • Log files — where component logs live on disk.
  • Maintenance tools — version information for every component.