Skip to main content

Blocking Chains: Metric Reference

This page is the source of truth for the in-app Explain this panels on the Activity Explorer Blocking Chains 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).

Active Chains​

The number of separate blocking chains detected in the selected time window. A blocking chain is one root blocker — a session holding a lock while not waiting on anything itself — plus every session queued behind it, directly or through other blocked sessions.

How it's calculated​

  • The Logstag agent samples live session and lock state on the activity interval (10 s by default).
  • Each blocked session is linked to the session blocking it.
  • Following those links upward builds a tree per root blocker — each tree counts as one chain.
  • The tile counts distinct chains seen in the window, with the current filters applied.

Source by engine​

EngineSource
SQL Serversys.dm_exec_requests.blocking_session_id
PostgreSQLpg_blocking_pids()

Example​

Blocking chain example diagram

One chain: session 52 holds the lock and runs; session 67 queues behind it. Deeper trees count as a single chain too.

Reading it​

Zero is the healthy state. One long-lived chain usually means a transaction was left open; many small chains point at hot rows or lock escalation on a busy table. Rising is shown red — more chains is always worse.

Longest Block​

The longest time any single session spent waiting on a lock inside the time window. It is a peak, not an average — one bad wait sets this number.

How it's calculated​

  • Each sample records every blocked session's accumulated wait time.
  • The tile keeps the maximum across all sessions and all samples in the window.
  • The value auto-scales to the largest sensible unit — 10.8 s rather than 10800 ms.

Example​

Lock wait durations with the maximum highlighted

Three blocked sessions in the window — the tile reports only the tallest bar, the single worst wait.

Reading it​

Compare it against your application's command timeout (commonly 30 s). A longest block approaching that line means requests failed, not just slowed down. The tile turns red when the window is marked Critical.

Blocked Sessions​

How many sessions were stuck waiting behind a blocker in the window. This is the human-impact number — each one is a request going nowhere.

How it's calculated​

  • Counts distinct sessions observed in a blocked state across all chains.
  • A session that is blocked and blocking others (amber in the table) is counted once.
  • Root blockers are not counted — they are running; everyone else is waiting.

Example​

Which sessions in a chain are counted

Two blocked sessions here: 67 waits on 52 while also blocking 71. The root blocker itself is never counted.

Reading it​

Read it together with Active Chains: many blocked sessions in one chain means a single hot resource; one blocked session per chain means scattered contention. Growth here while Active Chains stays flat means a queue is forming behind one blocker.

Deadlocks Detected​

How many deadlocks the engine resolved in the window. A deadlock is not slow blocking — it is a cycle of sessions waiting on each other that can never resolve, so the engine kills one of them.

How it's calculated​

EngineSource
SQL Serverxml_deadlock_report events from the always-on system_health XE session
PostgreSQLthe deadlock detector that fires after deadlock_timeout (1 s default)

The agent ingests these events; the tile counts them in the window.

Example​

Deadlock cycle between two sessions

A deadlock is a cycle — neither side can ever proceed, so the engine terminates one victim and rolls its transaction back.

Reading it​

Anything above zero deserves a look: each event rolled back a victim's transaction (SQL Server error 1205, PostgreSQL 40P01) and the application had to retry. Repeated deadlocks on the same pair of tables usually mean two code paths update them in opposite order.

Detected Chains​

Every blocking chain in the window, worst first. Each chain expands into the sessions inside it.

Example​

Annotated Detected Chains table rows

How to read the table: ① summary strip ② root blocker (red tint, Granted: Yes) ③ blocked sessions, indented by depth.

Columns​

  • PID — The session id (spid). The chain is keyed by its root blocker's PID.
  • Lock Type — Wait class: Locks, LWLocks, or IO.
  • Resource — What is being waited on, e.g. KEY: 6:72057594… (database : object).
  • Mode — Role in the chain: Holding, Blocked, or BlockedAndBlocking (amber).
  • Granted — Whether the session's lock request is granted. Only the root shows Yes.
  • Duration — How long the lock has been held (root) or waited on (blocked).
  • Query — The last statement seen on the session.

Tip: The share action opens the chain in the full Blocking Chain view. Killing the root blocker's session frees the whole chain — treat it as the last resort; first find the application that left the transaction open.