Databases
    Updated May 2026
    PostgreSQL logo

    PostgreSQL Monitoring

    Monitor PostgreSQL TPS, cache hit ratio, replication lag, idle-in-transaction sessions, autovacuum progress, and WAL generation in real time — agent-based via `pg_stat_*` views.

    Start Free TrialView Docs

    Why monitor PostgreSQL?

    PostgreSQL handles your transactional data — and quietly accumulates problems that surface as outages weeks later: replication drift, bloated tables, runaway autovacuum, idle-in-transaction sessions holding locks. Monitoring catches the signals early so you fix the root cause before a customer ticket forces emergency `VACUUM FULL` at 3am.

    Auto-discovery via Xitogent — no manual configuration required
    Real-time transaction and query throughput metrics
    Track connection pool usage and idle connections
    Monitor streaming replication lag and WAL status
    Vacuum and autovacuum performance tracking
    Dead tuple and table bloat monitoring
    Works on both Linux and Windows servers
    1-minute metric collection intervals
    What is PostgreSQL monitoring?

    PostgreSQL monitoring, explained

    PostgreSQL monitoring catches replication drift, runaway autovacuum, bloated tables, and idle-in-transaction sessions before they turn into outages or data corruption. For any Postgres workload — RDS, Aurora, CloudNativePG, self-hosted Patroni clusters — per-database visibility is the difference between catching a connection leak in 60 seconds and learning about it from a customer ticket. Xitoring auto-discovers your Postgres, queries the native pg_stat_* views with the pg_monitor role, and routes alerts to Slack, PagerDuty, Telegram, or your existing on-call.

    Metrics

    What we monitor

    Active Connections

    Number of currently active connections to the PostgreSQL server.

    Transactions per Second

    Rate of committed and rolled-back transactions.

    Tuple Operations

    Rate of inserted, updated, deleted, and fetched tuples across all databases.

    Dead Tuples

    Number of dead tuples waiting for vacuum, indicating potential table bloat.

    Cache Hit Ratio

    Percentage of data requests served from shared buffers without disk access.

    Replication Lag

    Bytes or seconds behind the primary in streaming replication.

    WAL Generation Rate

    Rate of Write-Ahead Log data being generated.

    Lock Waits

    Number of queries waiting to acquire locks on database objects.

    Temp Files Created

    Number and size of temporary files created for query processing.

    Database Size

    Total disk space used by each database including indexes.

    Idle in Transaction

    Connections that are idle inside an open transaction, potentially holding locks.

    Checkpoints

    Frequency and duration of checkpoint operations.

    Triggers & Alerts

    Configurable alert triggers

    Set up custom triggers in your dashboard to get notified the moment PostgreSQL metrics cross your defined thresholds.

    PostgreSQL monitoring trigger configuration dashboard

    Active Connections

    critical

    Fires when active connections approach max_connections, risking new connection refusal and application errors.

    Replication Lag

    critical

    Triggers when streaming replication falls behind, risking data inconsistency between primary and replicas.

    Dead Tuples

    warning

    Alerts when dead tuple count grows beyond threshold, indicating vacuum is falling behind and table bloat is increasing.

    Cache Hit Ratio

    warning

    Fires when cache hit ratio drops below threshold, indicating excessive disk I/O and potential memory pressure.

    Lock Waits

    warning

    Triggers when queries are blocked waiting for locks, indicating contention that degrades performance.

    Transaction Rate Drop

    critical

    Alerts when transaction throughput drops significantly, indicating a potential database hang or performance issue.

    01

    Importance of PostgreSQL Monitoring

    PostgreSQL handles mission-critical data for enterprises worldwide. Without proper monitoring, table bloat, replication drift, and connection exhaustion can lead to data corruption, outages, and unrecoverable failures.

    • Detect long-running queries and lock contention early
    • Prevent table bloat with vacuum performance tracking
    • Monitor streaming replication for data consistency
    • Identify connection leaks before pool exhaustion
    • Track WAL generation for storage capacity planning
    PostgreSQL monitoring dashboard with transaction metrics
    Database performance alert timeline
    02

    Why Choose Xitoring

    Xitoring delivers enterprise-grade PostgreSQL monitoring with zero-config setup. Our lightweight agent auto-discovers your PostgreSQL instances, starts collecting metrics in under 60 seconds, and integrates with your existing notification channels.

    • One-command install — no complex YAML or config files
    • 15+ global monitoring nodes for low-latency checks
    • Unified dashboard for servers, databases, and uptime
    • Flexible alerting via Slack, PagerDuty, Telegram & more
    • Historical data retention for capacity planning & audits
    Xitoring multi-database monitoring overview
    Notification channels and alert configuration
    Use cases

    Common PostgreSQL monitoring scenarios

    Where PostgreSQL typically runs today — and what could go wrong if no one's watching.

    Managed cloud database (AWS, Azure, Google)

    Cloud providers handle backups and patching, but they don't tell you when your own queries are slow, your connections are running out, or a backup copy is quietly falling behind the live one. We catch the issues the provider leaves to you, so an outage doesn't catch the team off guard.

    Self-hosted database with automatic failover

    If the main database fails, a backup copy is supposed to take over in seconds. But a backup that's quietly falling behind can turn that handoff into a 30-second outage — or worse, data loss. We watch every copy so you know it's truly ready to take over before you ever need it to.

    Database running inside Kubernetes

    Databases in Kubernetes get moved, restarted, and updated by the platform automatically. Most of the time it's safe — when it isn't, you usually find out from frustrated users. We surface the early warning signs so the team can step in before a routine update becomes an incident.

    Before you start

    Prerequisites for PostgreSQL

    Make sure you've got these in place — most installs are a 60-second job once they are.

    • PostgreSQL 12 or later (tested through PG 18 in 2026) running on the server
    • A user with the pg_monitor role (or equivalent SELECT grants on pg_stat_* views)
    • Optional: pg_stat_statements loaded via shared_preload_libraries for query-level metrics
    Setup Guide

    Get started in minutes

    1

    Install Xitogent on your server

    If you haven't already, install the lightweight Xitogent monitoring agent on your server.

    curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=YOUR_API_KEY
    2

    Create a monitoring user in PostgreSQL

    Create a dedicated read-only user for Xitogent to collect metrics:

    CREATE USER xitoring WITH PASSWORD 'your_secure_password'; GRANT pg_monitor TO xitoring; GRANT SELECT ON pg_stat_database TO xitoring;
    3

    Enable the PostgreSQL integration

    Use the Xitoring dashboard or CLI to enable the PostgreSQL integration with the monitoring credentials.

    sudo xitogent integrate
    4

    Configure alert thresholds (optional)

    Set custom thresholds for metrics like replication lag, dead tuples, or connection count to get notified when something needs attention.

    5

    Verify it's working

    Run this command on the server to confirm Xitogent picked up the integration. Fresh metrics will start streaming to your dashboard within ~30 seconds.

    sudo xitogent status
    Compare

    Considering alternatives?

    See how Xitoring stacks up against the alternatives for PostgreSQL monitoring — flat pricing, deeper integrations, and one agent that covers your whole stack.

    See all comparisons

    Frequently asked questions

    What is PostgreSQL monitoring?
    PostgreSQL monitoring is the continuous collection of database performance data from the native `pg_stat_*` views — connection state, transaction rate, cache hit ratio, replication lag, autovacuum progress, lock waits, WAL generation, temp files, and slow queries (via `pg_stat_statements`) — combined with alerting when those metrics breach thresholds. It's how teams catch idle-in-transaction sessions, runaway autovacuum, and replica drift before they cause outages.
    How do I monitor PostgreSQL cache hit ratio?
    Cache hit ratio is computed from `pg_stat_database`: `blks_hit / (blks_hit + blks_read) * 100`. Aim for 99%+ on OLTP workloads — anything below 95% means you're hitting disk a lot, usually fixed by raising `shared_buffers` or `effective_cache_size`. Xitogent computes and trends the ratio automatically per database; alert when it drops below your baseline.
    What is pg_stat_statements and how do I enable it?
    `pg_stat_statements` is the official PostgreSQL extension for query-level metrics — execution count, total/mean time, rows returned, shared-block hits/reads per query. Add `pg_stat_statements` to `shared_preload_libraries`, restart Postgres, then run `CREATE EXTENSION pg_stat_statements;` in each database. Xitogent auto-detects the extension and surfaces top-N slowest queries with `mean_exec_time` and call rate.
    How do I detect slow queries in PostgreSQL?
    Two approaches: enable `pg_stat_statements` for aggregated query metrics (best for trending), and set `log_min_duration_statement = 1000` (ms) to capture individual slow queries in the log for tools like pgBadger. For real-time investigation, query `pg_stat_activity WHERE state = 'active' AND query_start < now - interval '5 seconds'` to find queries running longer than 5 seconds right now.
    How do I monitor PostgreSQL replication lag?
    On the primary, query `pg_stat_replication` for per-replica `write_lag`, `flush_lag`, and `replay_lag` (intervals) plus the LSN gap `pg_current_wal_lsn - replay_lsn` (bytes). On the replica, `pg_last_wal_replay_lsn` and `pg_last_xact_replay_timestamp` give catch-up state. Xitogent surfaces both per replica and alerts when `replay_lag` exceeds your RPO budget.
    What is autovacuum and why does it matter?
    Autovacuum is the background process that reclaims space from dead tuples (rows deleted or updated) and prevents transaction-ID wraparound. If autovacuum falls behind, tables bloat (queries slow down, indexes become inefficient) and you risk XID wraparound — which forces a full read-only shutdown. Monitor `pg_stat_user_tables.n_dead_tup`, `last_autovacuum`, and `pg_stat_progress_vacuum` to catch issues before they require emergency `VACUUM FULL`.
    How do I monitor connection pool exhaustion and idle-in-transaction sessions?
    Query `pg_stat_activity` for connection state distribution (`active`, `idle`, `idle in transaction`, `idle in transaction (aborted)`). Idle-in-transaction sessions are particularly dangerous — they hold locks and block autovacuum. Set `idle_in_transaction_session_timeout = '5min'` to auto-terminate offenders, and alert when connection count approaches `max_connections × 0.8`. If you use pgbouncer, monitor its `pgbouncer` admin DB for pool stats.
    Does this work with managed PostgreSQL (RDS, Cloud SQL, Azure)?
    Yes — Xitogent connects over the network to any reachable Postgres endpoint with the `pg_monitor` role granted. Run Xitogent on an EC2/bastion host (or anywhere with network access to RDS/Aurora/Cloud SQL), point it at the endpoint with monitoring credentials, and metrics flow as if it were self-hosted. The same applies to CloudNativePG.
    What PostgreSQL versions are supported?
    PostgreSQL 12 through 18 (current as of 2026) are fully supported. PG 16 introduced `pg_stat_io` (per-backend I/O by object × context); PG 17 added `compute_query_id = auto`; PG 18 expanded `pg_stat_io` with byte-level columns and consolidated WAL I/O into the same view. The integration adapts to whichever version is present — newer views are read when available, older versions get the classic `pg_stat_*` set.

    Start monitoring PostgreSQL today

    Set up in under 60 seconds. No credit card required. Full metrics from day one.

    Start Free Trial

    Keep exploring

    Related Integrations