Health dashboard

The Health tab is the main system-level diagnostics page. It starts with a small set of summary cards, then shows detail sections for specific risks.

Use it when you want to answer questions like:

• Is the instance under checkpoint or I/O pressure?
• Are long transactions blocking cleanup?
• Is wraparound risk building up?
• Are replication slots or statement statistics becoming a problem?

Top-level cards

Card	What it means
Cache hit ratio	Whether reads are mostly served from cache or falling through to disk. Measured over a recent window rather than as a lifetime average since the last statistics reset, so a long-running server cannot mask recent cache pressure. Saved instances also get 7-day baseline context.
Connections	Current connection usage relative to the configured ceiling. Drawn from client backends only — autovacuum workers and background processes are excluded.
Oldest transaction	Whether a long-running transaction may be blocking vacuum progress or tuple cleanup. Null when no active transactions exist.
TXID wraparound risk	Whether transaction ID age or multixact age is approaching a dangerous range. Shows the worst of XID and MXID as a percentage of the 2.1B limit.

The UI shows the current value, severity, and explanation. For saved instances, each card also includes baseline context — whether the current value is anomalous compared to the 7-day average.

Detail sections

• Checkpoint stats show timed vs requested checkpoints, checkpoint write/sync time, and related pressure signals. On managed providers, checkpoint frequency may partly reflect provider activity rather than only application writes.
• Sequences at risk show sequences that are getting close to their maximum value.
• Replication slots show WAL retained by non-temporary slots. This matters because an inactive or stalled slot can keep WAL files on disk for too long.
• pg_stat_statements capacity shows whether the statement statistics store is evicting entries before they remain useful.
• bgwriter maxwritten shows whether the background writer is repeatedly hitting its configured limit.
• Vacuum horizon blockers show sessions with old snapshots that can hold back dead tuple cleanup.
• Configuration & durability checks flag risky settings: autovacuum off, fsync or full_page_writes off, SSL disabled, weak password_encryption (md5), slow-query logging disabled, no statement_timeout, and superuser sprawl.

Every finding includes a fix

Findings are not just descriptions. Where a safe remediation exists, the finding carries the exact SQL to apply it — an ALTER SYSTEM SET …, a targeted VACUUM, a REINDEX … CONCURRENTLY, or a sequence widening — along with whether the change needs a restart or a reload and the caveats that matter. The SQL is always copy-to-run: pocketPG never executes it for you. The same fixes appear next to findings in the daily digest and webhook alerts.

Health score and priorities

The individual findings roll up into a single health score from 0 to 100 and a priority ranking, so you can judge an instance at a glance and triage in order.

Priority	Severity	Read it as
P1	CRITICAL	Act now — data-loss, corruption, or imminent-failure risk
P2	HIGH / WARNING	Address soon — active degradation or a building risk
P3	MEDIUM	Worth scheduling
P4	LOW	Informational

The score reflects severity, not volume: a single P1 weighs far more than a long list of P4 notes, so a flood of low-severity items can never drown out one real problem. A clean instance scores 100. The score and its P1–P4 breakdown accompany the findings delivered through webhook alerts.

Failure readiness

Two summary cards estimate recovery posture:

• Crash Recovery (RTO) is a rough signal for how much recovery work may be needed after a crash.
• Data Safety (RPO) is a rough signal based on replica state, sync mode, and WAL retention hazards.

These are operational summaries, not a substitute for tested disaster recovery procedures.

Snooze

Findings can be snoozed locally so accepted conditions do not keep interrupting the current investigation.

Caching

Health data is short-lived cached. Existing content stays visible while a fresh read is loaded in the background.