What Happened?

What Happened? answers one question: what was wrong with this instance at this moment, and what should I do about it.

It works on data WISdom has already collected, at the same 1-minute collection frequency used across the other monitoring screens, so a single minute is roughly what sp_WhoIsActive would have shown you at the time. What Happened? reads every minute in the window you choose, runs its diagnostic checks against each one, ranks what it finds, and tells you which minutes deserve your attention.

It is not a live view and it is not a simulation. Nothing replays and nothing is modelled. Every value on the screen was measured at the time it happened. If WISdom was not collecting during a minute, that minute has nothing to show.

When to use it

An alert fired overnight and you want to know what was actually happening.
Someone reports “it was slow around 3pm” and you need the 3pm story.
A job or a deployment ran at a known time and you want to see its impact.
You want to prove an instance was genuinely healthy during a window, not just that nothing alerted.

Running an analysis

Go to Performance › What Happened?. Before an analysis has run, the screen offers a single Start Analysis button.

The What Happened? screen before an analysis has run

Set three things:

Control	What it does
Server	The instance to analyze.
Date and time	The moment you care about. This is the end of the window, not the middle.
Window	How far back to look: 15 min, 30 min, or 1 hour. A 1 hour window ending at 12:03 analyzes 11:03 to 12:03.

Run it, and the controls stay at the top of the results so you can adjust and re-run. Start New Analysis begins a fresh one; Reset clears the current result and returns the controls to their defaults.

Pick the window deliberately. A 15-minute window around a known event gives a dense, readable timeline. A 1-hour window is better when you are not sure when the problem started, at the cost of each minute being a thinner slice.

At a glance

At a glance summarizes the whole window. It has two forms, and which one you get is the first thing to read.

When nothing was found

An ALL CLEAR badge and a line reading “All 60 minutes were normal.” The timeline is solid teal, and What we found is replaced by a confirmation: “We checked 18 things. All of them came back clear. Nothing on ServerName\INST01 between 05:48 and 06:48 needs your attention.”

This is a result, not an empty screen. Every diagnostic check ran against every minute of collected data and none fired. Use it as evidence, especially when a reported slowdown lands in a window that turns out to be clean.

When something was found

A SUMMARY badge reading “X of Y minutes had a finding impacting them,” where Y is the window length in minutes (15, 30, or 60). Beside it, one colored count per severity that occurred, for example “51 Medium · 8 High · 1 Critical.”

Those counts are a readout only. They do not filter the timeline and they do not filter the findings list.

The timeline

OVERALL / every finding, by minute plots each minute in the window as one colored block.

Color	Severity
Teal	Normal
Yellow	Medium
Coral	High
Red	Critical

A minute’s color is a relative signal, not a fixed threshold. It reflects how much diagnostic activity WISdom found in that minute: how many checks fired, and how strong each signal was. Normal means little or nothing was flagged. Medium, High, and Critical climb from there as more checks fire together or their signals strengthen, with Critical marking the minutes most likely to need you.

Hover a legend swatch to isolate that severity: matching minutes stay lit and the rest fade to black. Move away to restore the timeline. Hover is the only interaction here. Clicking a legend swatch does nothing, and this is not the gray-out legend toggle used on Performance Metrics charts.

Why the numbers will not add up

This trips people up, so it is worth stating plainly.

The severity counts in the summary describe minutes, and each minute is counted once, at the severity of the worst thing happening in it. The minute counts on the finding cards describe findings, and every finding counts every minute it affected.

So a window with “Resource-Heavy Query 60 of 60 min”, “Buffer Pool Pressure 8 of 60 min”, and “Deadlock 1 of 60 min” sums to 69 minutes inside a 60-minute window, while the summary reads “60 of 60 minutes.” Nothing is broken. Those minutes overlap: the summary counts minutes, the cards count findings.

The only row that sums meaningfully is the severity row, which always totals the number of affected minutes.

What we found

What we found lists every check that returned a finding, most affected minutes first.

Category badges across the top: All, plus one badge per category present in the results, such as Query & Session, Blocking & Deadlocks, or Memory, each with its count. Only one can be active at a time. Select a category to narrow the list, or All to clear it.
Finding cards, each showing the name, how many minutes it affected (“8 of 60 min”), and its own mini timeline so you can see whether it was constant or clustered. Click a card or its chevron to drill in.

The shape of a card’s timeline is diagnostic on its own. A finding spread evenly across every minute is usually a workload characteristic. A finding clustered into a few adjacent minutes is usually an event, and the edges of that cluster are where to look.

The diagnostic checks panel

View all 18 checks in the top-right corner opens a side panel listing every check WISdom evaluated, not only the ones that fired. The header shows how many fired against how many stayed clear.

Checks that fired are listed first, each with a warning icon and a colored pill for minutes affected. Checks that stayed clear follow, grouped by resource area (Throughput, Contention, CPU, Memory, Storage, Blocking & Deadlocks), each with a green Clear pill. Hover the info icon beside any check for a tooltip defining what it evaluates.

Open this panel when you need to say what was ruled out, not just what was found.

What each finding means

Every check has a reference page covering what it detects, why it happens, what to look at, and how to fix it. Read those alongside a live finding.

Category	Findings
Query and session	Resource-Heavy Query · Duplicate Query Storm · Application Overload · High Query Concurrency
Blocking and deadlocks	Blocking · Deadlock · Database Contention Pressure
Memory	Buffer Pool Pressure · Host Memory Pressure · Database Memory Pressure
CPU	Host CPU Pressure · Database CPU Pressure
Storage	Host Storage Pressure · Database Storage Pressure
Plans and compilation	Excessive Plan Compilation · Excessive Plan Recompilation
Connections and throughput	Connection Surge · Transaction Surge · Resource Bottleneck

The full list with definitions is in the findings reference.

Drilling into a finding

Click a finding to open its detail view. The breadcrumb confirms exactly what you are looking at:

Server: ServerName\INST01 → Range: 02:30 - 03:30 → Rule: Resource-Heavy Query

Back to Findings returns you to the list without losing the analysis.

A mini timeline sits below, colored the same way as At a glance and scoped to the window. Below that, Prev and Next step between minutes, with the selected timestamp between them.

Two things about stepping that are easy to miss:

Prev and Next skip Normal minutes. They jump to the next minute where this specific rule fired, not the next minute on the clock.
Normal minutes are never selectable, whether you step or click the timeline directly. There is nothing behind them for this rule.

Which tabs you get

The set of tabs tells you something about the finding.

Tab	When it appears
Findings	Always.
Activity	Always.
Metrics	On findings with specific measurements behind them, which is most of them.
Blocking Details	Blocking findings only.
Deadlock Details	Deadlock findings only.

Findings tab

The diagnosis, in six parts.

Rule name and description. What the check looks for and what it saw. For a Resource-Heavy Query this reads like “The same statement has been observed around the same time (±15 minutes) in 4 of the 4 past weeks. The statement’s impact is 30% lower than the historical max.” Read this line first. It usually decides whether you are looking at a recurring workload pattern or a one-off event.
View button, top right, labeled to match the finding: View Query Details, View Blocking, or View Deadlock. It opens the matching Performance page in a new tab, filtered to the same instance, database, and blocking or deadlock group. That page uses its own date range, not the window you analyzed here, which is what you want when you need to know whether this chain has happened before.
KPI cards: Running Sessions, CPU Health, Memory Health, and Storage Health, each with a value or status and a percent change from the previous period. The previous period is the window of the same length immediately before the one you analyzed.
Statement box, the SQL involved. Labeled Lead Blocker Statement on Blocking findings.
Supporting information, the measurements behind the finding. See Reading the comparisons.
What to do, three ranked recommendations, each a short title and a sentence or two. They are ordered deliberately: fix the cause first, adjust the application second, spend money last. Work down the list, not up it.

Reading the comparisons

Supporting information has three columns: the metric, its value at the selected minute, and how that value compares with the past 4 weeks. The third column is where the judgement lives.

What you see	What it means
POINT-IN-TIME VALUE	Descriptive, not comparable. Session ID, database, object, host, login, and application identify the activity; there is no meaningful history for them.
A percentage against a 4-week max	The comparison that matters. “30% below the 4-week max of 34,183” means this is normal for this workload. “0% above the 4-week max of 96” means you are at the ceiling.
First Seen - No History	WISdom has no prior observation of this metric for this statement. Treat it as new behavior, and worth a look.

A finding whose numbers all sit well under their 4-week maxima is usually telling you this workload is always like this. A finding at or above its maxima is telling you today is different.

Activity tab

Every active process at the minute shown above the tabs, in a sortable grid.

On query and session findings (Resource-Heavy Query, Buffer Pool Pressure, Application Overload, Duplicate Query Storm) a toggle switches between:

Filter to this finding, only the flagged session.
Show all, every active session during that minute.

Show all also makes the mini timeline clickable, so you can jump to any minute that had a finding instead of stepping with Prev and Next. Normal minutes still cannot be selected.

Blocking and Deadlock findings have no toggle. Their Activity tab always shows every active process for the minute, and Prev and Next are the only way to move.

Hover the Active Processes panel to reveal Ask Advisor in the top-right corner, hidden until you do. It opens WISdom Advisor with that activity data.

The grid has a search icon and a column chooser (the sliders icon) for: Time, Session, Run Time, Instance, Database, Object, Status, Blocked By, Parallel Threads, Wait Category, Wait Type, Wait Time, CPU, IO, Application Host, Login, Program, and SQL Statement. Blocked By is hidden by default; the rest are shown. Use Rows per page and the Total rows count to page through.

Read Status before anything else in the grid. A RUNNING session is consuming resource. A SUSPENDED session is waiting, and its Wait Category and Wait Type tell you what for.

Metrics tab

Charts of the measurements behind the check, plotted across the window.

Blocking and Deadlock findings plot Full Scans/sec and Table Lock Escalations/sec for the instance.
Buffer Pool Pressure plots Page Life Expectancy, Checkpoint Pages/sec, and Lazy Writes/sec.
Other findings plot whichever metrics are relevant to what they check.

Display opens the same Auto-Scale, Host Pressure, and Database Pressure toggles found on Performance Metrics charts. All three are off by default here. Hover the chart for exact values at a minute; the legend below shows the average across the full window.

Blocking Details tab

Blocking findings only. Three sub-tabs.

Sub-tab	Columns
Resources	Lead Blocker, Session ID, CPU, IO, Parallel Threads, Granted Memory, Object, SQL Statement
Wait Statistics	Lead Blocker, Session ID, Wait Statistics, Wait Resource, Wait Time, Object, SQL Statement
Application	Lead Blocker, Session ID, Application Host, Login, Program, Object, SQL Statement

Each sub-tab flags the head of the chain with an orange LB badge in the Lead Blocker column, and carries a View Blocking button top right. There is no file download here, because a blocking chain does not produce a graph file the way a deadlock does.

Start at the LB row. The head of the chain is what you act on; everything below it is a victim.

Deadlock Details tab

Deadlock findings only. Two sub-tabs.

Sub-tab	Columns
Processes	Application, Host, Login, Isolation Level, SQL Statement, Input Buffer
Resources	Object Name, Index Name, Resource Type, Meta Data Lock Info

Both carry View Deadlock and Download XDL File top right. Download XDL File saves the SQL Server deadlock graph (.xdl) for the event, which opens in SSMS or any XML deadlock graph viewer for node-by-node analysis.

A row can show unknown for SQL Statement or N/A for Input Buffer. That is not a gap in WISdom. It means the deadlock graph SQL Server produced did not carry that detail for that process, which is common for a process already chosen as the victim and rolled back. Download the .xdl when you need everything SQL Server recorded.

A worked example

An instance is reported slow overnight. You set Server to the instance, the time to 03:00, the window to 1 hour, and run the analysis.

At a glance reads “60 of 60 minutes had a finding impacting them,” with 51 Medium, 8 High, and 1 Critical. The strip is coral for the first eight minutes, yellow across the middle, with one red block at 03:00.
What we found lists three findings: Resource-Heavy Query (60 of 60 min), Buffer Pool Pressure (8 of 60 min), and Deadlock (1 of 60 min). The card timelines give you the shape immediately: the query ran the whole hour, the memory pressure was confined to the first eight minutes, the deadlock was a single event at 03:00.
The coral opening is where Buffer Pool Pressure overlapped the query. The one red minute is the deadlock. Neither is the constant finding, which matters: the finding covering the most minutes is not necessarily the one to fix.
Open Deadlock, the Critical minute. Read the description, then Deadlock Details › Processes for the applications involved, then download the .xdl if you need the full graph.
Open Buffer Pool Pressure and check its Metrics tab. Page Life Expectancy collapsing during those eight minutes points at memory; steady PLE points elsewhere.
Open Resource-Heavy Query last. Its description says the same statement ran at this time in 4 of the past 4 weeks at 30% below its historical max. That is a known nightly workload running normally, so it is context for the other two findings rather than the thing to chase.

The order matters. Work from the narrowest, most severe finding outward, and use the 4-week comparisons to separate “this is always like this” from “this is different tonight.”

Common questions

All clear, but someone reported a problem. What now? All clear means no check fired on collected data in that window. Widen the window, confirm you have the right instance, and check the clock: the time you pick is the end of the window, so an event at 03:10 does not appear in a 1-hour analysis ending at 03:00.

Why is a minute Critical when only one finding covers it? Severity reflects signal strength as well as count. One check firing hard is enough to make a minute Critical.

Why do the per-finding minute counts exceed the window length? They overlap. See Why the numbers will not add up.

Does What Happened? collect query plans? No. WISdom does not collect query plans. It does not pull them into the product and does not store or display them anywhere. Query plans are analyzed as one input to the recommendations under What to do, so you do not have to read one.

Can I analyze a window with no collected data? No. What Happened? only reads what was collected, so a gap in collection is a gap here. Check Collector Health if a window comes back empty when you expected findings.