Monitoring Best Practices
Good PostgreSQL monitoring tells on-call whether users are hurting and where to look first. These rules keep signal high and pager fatigue low across self-hosted and managed deployments.
//
Search across all documentation pages
Good PostgreSQL monitoring tells on-call whether users are hurting and where to look first. These rules keep signal high and pager fatigue low across self-hosted and managed deployments.
cl_waiting alert before Postgres max_connections.Start with 5-8. Add when an incident was blind, not preemptively for every gauge.
Yes for query workload and app correlation. CloudWatch alone misses pg_stat_statements ranking.
Platform rotation for infra saturation; app on-call for SLO burn with DB drill-down handoff.
Metrics for paging; logs for forensics after pointer from dashboard.
Canary write/read path every 1m complements metrics; not a replacement.
Never label Prometheus metrics with query text or user id.
Separate row for replay lag and conflict counts; do not merge with primary TPS blindly.
Monitor uptime only; no production alert routing.
Single panel: active sessions, lock waits, lag, disk - optimized for screen share.
Sample high-cardinality traces; keep DB metrics in Prometheus for cheap retention.
Stack versions: This page was written for PostgreSQL 18.4 (stable 18, maintenance 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, and PostGIS 3.5+.
Reviewed by Chris St. John·Last updated Jul 16, 2026