How to read pg_stat_activity

pg_stat_activity is a dynamic view with one row per PostgreSQL server process. For client backends, it can show the database, role, application label, connection and transaction timestamps, current state, and wait event.

It is a current observation, not cumulative history. A session can change state immediately after your query, and PostgreSQL does not fully synchronize every field in the row.

This bounded, read-only summary omits the query, client address, and process identifier. It excludes the inspecting session and groups the remaining connections by safe operational dimensions.

SELECT
  COALESCE(usename, 'unknown') AS role_name,
  COALESCE(NULLIF(application_name, ''), 'unlabeled') AS application_name,
  COALESCE(state, 'unknown') AS state,
  wait_event_type,
  wait_event,
  count(*) AS session_count,
  min(backend_start) AS oldest_connection_start,
  min(xact_start) AS oldest_transaction_start,
  min(CASE WHEN state = 'active' THEN query_start END) AS oldest_active_query_start
FROM pg_stat_activity
WHERE datname = current_database()
  AND pid <> pg_backend_pid()
GROUP BY usename, application_name, state, wait_event_type, wait_event
ORDER BY session_count DESC, role_name, application_name
LIMIT 50;

state and wait_event are independent. An active backend with a non-null wait event is executing a query but blocked somewhere, while a client wait can simply mean PostgreSQL is waiting for the application to send more work.

Wait-event types identify broad areas such as locks, client communication, I/O, IPC, buffer pins, timeouts, and extension-defined waits. The event supplies evidence about where a backend is paused; it does not identify the root cause by itself.

1. Start with grouped counts and timestamps rather than query text or client addresses.
2. Compare connection count with the configured limit and with an understood application baseline.
3. Review the oldest active query and transaction ages, then confirm whether scheduled or administrative work explains them.
4. For waiting active sessions, inspect the wait type before assuming CPU, storage, or locking is responsible.
5. Repeat observations over time before labeling a transient snapshot as sustained pressure.

• Many idle connections do not necessarily mean PostgreSQL is overloaded; pool design and available connection capacity matter.
• An active session is not necessarily consuming CPU at that moment.
• A wait event is not automatically an error, and a null wait event does not prove healthy execution.
• A long-running query or transaction can be intentional maintenance or reporting work.
• The query field shows the last query for non-active sessions, not a query that is still running.

The PostgreSQL health check returns bounded counts for active, idle, idle-in-transaction, waiting, long-running query, and long-transaction sessions without returning SQL text, process identifiers, or client addresses.

Connected telemetry stores grouped application, role, state, and connection-count observations. That supports comparisons over time while preserving the distinction between a one-time session snapshot and a sustained connection pattern.