Wait Events: Metric Reference

This page is the source of truth for the in-app Explain this panels on the Activity Explorer Wait Events tab. Each section is written once as a content partial under _explain/ and rendered both here and inside the dashboard's info panel (scripts/build-explain.mjs compiles the registry).

The Wait Events tab is available for PostgreSQL, Microsoft SQL Server, and Oracle databases.

Wait Events

The number of wait events captured on this database in the selected time window — sessions observed waiting on something instead of executing.

How it's calculated

• The Logstag agent samples live session state on the activity interval (10 s by default) and records the wait each session is in, if any.
• The tile counts the waits observed in the window, with the tab's filters applied; the trend arrow compares against the preceding window of the same length.
• The tile turns amber or red when the count crosses the warning or critical threshold; every metric on this tab treats rising as worse.

Reading it

Some waiting is normal — databases coordinate through locks and latches by design. What matters is the change: a count that doubles against the previous window deserves a look at the history chart to see which category grew. Locks growing means contention between sessions; IO growing means storage pressure; Client growing usually means slow consumers on the application side.

Locks

The number of wait events in the Locks category — sessions waiting for a lock held by another session.

How it's calculated

• Waits whose engine-native type maps to Logstag's Locks category: Lock and BufferPin waits on PostgreSQL, LCK_* wait types on SQL Server, and the Concurrency and Application wait classes on Oracle.
• Counted over the selected window with the tab's filters applied; amber and red follow the same warning and critical thresholds as the other tiles here.

Reading it

Lock waits are the most actionable wait category, because there is always another session to look at: something holds what this session wants. When this tile is elevated, the Blocked Processes tile tells you how many sessions are stuck, and the Blocking Chains tab shows who is at the root. Brief lock waits under a write-heavy workload are normal; long ones almost always trace back to a transaction that stayed open longer than intended.

Blocked Processes

The number of sessions that were blocked by another session in the selected window — waiting on a lock someone else holds.

How it's calculated

• The agent's activity samples record, for each waiting session, which session blocks it (pg_blocking_pids() on PostgreSQL, blocking_session_id on SQL Server, blocking_session on Oracle).
• The tile counts distinct blocked sessions observed in the window, with the tab's filters applied.
• Amber and red follow the tab's warning and critical thresholds; rising is worse.

Reading it

This is the human-impact number: each unit is a session going nowhere. One or two blocked sessions that clear within a sample interval are everyday contention. A stable or growing count means a blocker is not letting go — open the Blocking Chains tab, find the root blocker, and read its query text. The fix is almost always at the root, not at the blocked sessions.

Potential Deadlocks

An indicator of deadlock risk in the selected window. It counts situations that look like they could end in a deadlock — it is not a count of deadlocks the engine has already killed.

How it's calculated

Engine	Source
PostgreSQL	Distinct blocking-chain roots observed in the window — each chain of sessions queued behind one blocker counts once.
SQL Server	The engine's own deadlock rate counters, averaged over the window.
Oracle	The change in the cumulative lock deadlock retry event counter (v$system_event) within the window.

The tile turns amber at the first potential deadlock and red as they accumulate; rising is worse.

Reading it

Zero is the expected state. A non-zero value is an early warning, not a confirmed incident — the engines resolve true deadlocks themselves by killing a victim, and this tile is designed to light up before that happens. When it does, the Blocking Chains tab shows the structure at risk: chains where two sessions each hold what the other wants are the ones that convert into real deadlocks.

Wait Events History

A stacked history of wait events by category across the selected window. Each bar is a sample bucket; each color is one wait category, and the legend toggles categories on and off.

The categories

Every engine has its own wait taxonomy — PostgreSQL has wait event types, SQL Server has hundreds of wait types, Oracle has wait classes. Logstag maps them all onto five shared categories so the chart reads the same everywhere:

• Locks — PostgreSQL Lock and BufferPin; SQL Server LCK_*; Oracle Concurrency and Application wait classes.
• LW Locks — PostgreSQL LWLock; SQL Server LATCH_*; Oracle Configuration wait class.
• IO — PostgreSQL IO; SQL Server PAGEIOLATCH_*, WRITELOG, IO_*, PAGELATCH_* and other buffer, memory and log waits; Oracle User I/O and System I/O wait classes.
• Client — PostgreSQL Client and IPC; SQL Server network waits such as ASYNC_NETWORK_IO; Oracle Network wait class.
• Other — everything an engine reports outside the categories above.

The mapping is deliberately lossy — it trades engine-native precision for cross-engine comparability. The table below the chart keeps the native event name on every row, so nothing is lost for drill-down.

Reading it

Read the dominant color first. Lock-dominated windows point at transaction design and hot rows; IO-dominated windows point at storage, checkpoints, or a working set that outgrew memory; Client-dominated windows usually mean the application reads results slowly and the database is waiting on it. A category that appears only at fixed times of day is a scheduled job announcing itself.

Current Wait Events

One row per waiting session observed in the selected window, showing its most recent wait. Click a row (or its eye icon) to open the full detail in place — session identity, the event, timing metrics, and the complete query text.

Columns

• PID — the engine's session identifier for the waiting session.
• Type — the shared wait category badge: Locks, LW Locks, IO, Client, or Other (see the category mapping on the history chart).
• Event — the engine-native wait name, unmapped: the wait_event on PostgreSQL, the wait_type on SQL Server, the event name on Oracle. This is the string to search engine documentation for.
• Resource — the object or resource associated with the wait, when one can be determined; otherwise a dash.
• Duration — how long this session has been in its current wait, measured with the database server's own clock.
• Count — how many sessions were observed in this same wait event alongside this one.
• Time — the average wait duration across those sessions.
• Query — the statement the session is executing, clamped to two lines; open the row detail for the full text.

Columns can be filtered individually, sorted where the header allows it, and shown or hidden from the column picker — visibility choices persist in your browser.

How it's calculated

• The Logstag agent samples live session state on the activity interval (10 s by default); each waiting session appears once with its latest wait.
• Count and Time aggregate across sessions sharing the same event, so a hot event reads the same from any of its rows.

Source by engine

Engine	Source
PostgreSQL	pg_stat_activity — wait_event_type and wait_event columns
SQL Server	sys.dm_exec_requests wait columns (wait_type, wait_time, wait_resource) joined with session and connection views
Oracle	v$session (event, state, wait timing), with wait-class enrichment from v$system_event

Reading it

Group mentally by Event: five rows with the same event and a high Count is one problem, not five. A single row with a long Duration and Locks type is a victim — its detail shows the blocking session. Events you don't recognize are worth the lookup: engine wait names are precise, and the engine's documentation for that exact string usually names the subsystem under pressure.