PostgreSQL Waits shows wait information that helps explain why sessions are delayed. Use it to diagnose lock waits, I/O waits, client waits, and other bottlenecks.
The PostgreSQL Waits page includes the Mini DBA Time Range selector. Use Live for current wait evidence, or switch to Last Hour, Last 12 Hours, Last Day, Last Week, or Custom to review historical wait rows. Mini DBA loads and caches the selected historical waits dataset for the current console session and server context, so comparing the loaded wait period with activity, I/O, and memory evidence stays quick. Use Back to Live to resume live updates, then choose another historical range when you need a different incident window.
PostgreSQL waits explain what sessions are waiting for, which is often more useful than looking at CPU alone. A slow query may be badly written, but it may also be waiting behind a lock, reading from slow storage, waiting for the client, or competing with background maintenance. The Waits page helps turn a vague performance complaint into a specific investigation path.
Look for waits that dominate the period you are investigating. Lock-related waits usually point to transaction design, blocking sessions, or long-running write activity. I/O waits can indicate missing indexes, large scans, storage pressure, or checkpoint behavior. Client waits can mean the database has returned data but the application is slow to consume it. Memory and buffer-related evidence should be compared with PostgreSQL Memory.
Waits should not be treated as errors by themselves. Every busy database waits on something. The goal is to identify waits that are unusual for the workload, increasing over time, or directly connected to a user-facing slowdown.
No. Waits are normal. They become important when they are excessive, new, recurring during incidents, or tied to slow application requests.
Use PostgreSQL Activity for current sessions and PostgreSQL Queries for expensive statements. Matching database, user, timing, and statement text helps connect the evidence.
Find the blocker first. A blocked query is often a symptom, while the blocking transaction is the cause.