Blocking Analysis is the real-time blocking investigation module. It combines live blocking snapshots, head-blocker identification, history captured by the application, export actions, and a detailed Session Inspector so you can understand who is blocking whom and decide whether intervention is safe.
- Detect active blocking chains and identify head blockers.
- View the same incident as graph, tree, timeline, and head-blocker list.
- Inspect SQL text, locks, plan summaries, and impact analysis for a selected session.
- Export snapshots, reports, audit logs, and captured history.
- Kill a session only after reviewing safety and impact signals.
- Top action bar
- Severity and quick-action area
- Main work area with left-side tabs
- Right-side Session Inspector
- Footer summary cards
- The module collects a live blocking snapshot with a background worker.
- Auto-refresh runs every 5 seconds when enabled and the view is visible.
- If no active connection exists, auto-refresh is turned off and the view shows a disconnected hint.
- Auto-Refresh toggle and Refresh Now
- Export CSV, Report, Audit CSV, and History CSV
- AI Brief
- Investigate and Kill Top Blocker
- Low: wait below 5 seconds
- Medium: 5 to 30 seconds
- High: 30 to 60 seconds
- Critical: 60 seconds or higher
- Database, User, Application, and Severity
- Min Wait and Max Wait
- Critical Only, Production DB, and Head Blockers quick filters
- Saved filters, alert rules, and webhook settings
These are the top-level numbers that tell you how serious the current blocking picture is before you inspect individual sessions.
Counts blocking sessions by wait-time severity. The severity banner and quick summary use the latest live snapshot, not long-term history.
Low is under 5 seconds, Medium is 5-30 seconds, High is 30-60 seconds, and Critical is 60 seconds or more.
Shows the total number of blocking sessions detected in the current refresh. It is the fastest indicator of whether the problem is isolated or widespread.
Rising totals usually mean more of the workload is being delayed, even if one head blocker is responsible.
Counts sessions that sit at the top of a blocking chain and are directly or indirectly blocking others.
A small head-blocker count with many blocked sessions usually points to a concentrated root cause.
Shows the highest single wait time seen in the current blocking snapshot.
This is a fast severity signal. A high Max Wait means at least one session has been blocked long enough to deserve immediate review.
Counts how many sessions are impacted by current blocking, not only how many sessions are themselves blockers.
Use this together with Head Blockers to estimate blast radius. One blocker can affect many sessions.
Shows how many separate blocking chains exist in the current snapshot.
More chains usually mean the issue is broad or concurrent, while one chain suggests a concentrated incident.
Shows the deepest blocker-to-blocked hierarchy currently visible.
A deeper chain means delays are cascading through multiple downstream sessions.
Represents the combined blocked wait time across the current blocking set.
Use it to gauge total pain, not just the worst single session.
These numbers help you understand each blocker or blocked session in more detail after you move past the summary level.
Shows how long the selected or listed session has been waiting on its current blocking condition.
Use this to prioritize urgent cases. Longer wait usually means higher user-facing impact.
Shows how far down the session appears in the current blocking hierarchy.
Depth 0 or root-level items are usually the origin side of the chain. Higher depth values are downstream victims.
Counts how many sessions are directly or indirectly blocked by the selected head blocker.
Higher blocked count means the session has a wider operational impact.
Shows CPU time associated with the session in seconds on the head blocker list.
High CPU on a blocker can suggest that the blocking session is both expensive and disruptive.
Shows how many sessions the selected session is blocking immediately, before counting deeper descendants.
Use this to distinguish a direct head blocker from a session that is only part of a larger chain.
Indicates whether the current UI and model consider the session a safe kill candidate.
Safe does not mean risk-free. Unsafe sessions are blocked or warned due to system, replication, backup, restore, or protected-command rules.
Appears in the Session Inspector summary to show how deep the selected session is inside the current chain.
Use it together with Direct Blocked Sessions and Blocked Count to understand whether the session is a root cause or a downstream victim.
Groups lock details by resource type, lock mode, status, resource, and count for the selected session.
Large counts or waiting and converting lock states usually mean the session is holding or requesting contested resources.
These numbers help you understand whether blocking is recurring, getting worse, or likely to improve if intervention happens.
Shows how many application-captured blocking snapshots exist for the recent timeline window.
Low snapshot count can simply mean the app was not open or the module was not refreshing.
Shows the average combined wait time across the captured timeline snapshots.
Use this to judge whether the incident is a spike or part of a persistent pattern.
Shows the deepest blocking chain observed across recent saved snapshots.
A high peak suggests that at least one prior incident cascaded far beyond a simple two-session block.
Shows the most recent total blocked wait seen in the timeline snapshot series.
Compare it with Avg Total Wait to see whether the current state is better or worse than the recent norm.
Estimated number of sessions that could be released if the selected blocker is removed.
This is a heuristic estimate, useful for triage but not a guarantee.
Shows the highest blocked wait that may be relieved by intervening on the selected session.
High peak impacted wait means at least one downstream session is suffering heavily.
Shows the combined blocked wait that may be improved if the selected blocker is removed.
Use this to estimate overall benefit instead of focusing on only one downstream victim.
A heuristic estimate of how quickly blocking pressure may unwind after killing or resolving the selected session.
Treat this as guidance only. Real recovery depends on rollback cost, workload shape, and transaction state.
- Filter controls visibility, notifications, and saved presets.
- Graph renders blocking chains visually and supports PNG export.
- Tree shows exact chain hierarchy with per-session columns.
- Timeline shows application-captured blocking history for the last 24 hours.
- Details shows a compact head-blocker list.
- SQL Statement shows session identity, severity, safety, and current SQL text.
- Locks groups lock details by resource type, mode, status, and count.
- Execution Plan shows plan summary, warnings, and XML preview when available.
- Impact Analysis estimates sessions affected, risk, and recovery considerations.
- History shows recurring-blocker presence captured by the application.
- If Head Blockers is low but Affected Sessions is high, one or two sessions are likely causing a broad outage.
- If Max Wait and Total Wait Time are both high, the problem is both severe for individuals and expensive overall.
- If Max Chain Depth is rising, blocking is cascading through dependent work rather than staying isolated.
- If Blocked Count is high on one session, investigate that blocker before drilling into downstream victims.
- If Timeline Avg Total Wait and Latest Total Wait both stay high, the issue is likely recurring rather than a short spike.
- If Safe To Kill is negative, review the session carefully before considering intervention.
- Open Blocking Analysis and take a fresh snapshot or leave auto-refresh enabled.
- Read the severity banner and quick summary before drilling into one session.
- Use Graph for shape, Tree for exact hierarchy, and Details for a compact blocker list.
- Select a session and review SQL Statement, Locks, Execution Plan, and Impact Analysis together.
- Use Timeline and History when you need to know whether the blocker is recurring.
- Kill a session only after reviewing safety and likely impact.
- The module is an investigation and response surface, not an auto-remediation tool.
- Timeline and recurring history depend on snapshots previously captured by this application.
- Production DB is a simple name heuristic, not a formal environment flag.
- AI Brief is a local heuristic summary in the current build, not a full LLM workflow.
- Killing a session always requires explicit confirmation and can still be rejected by safety validation.