Deadlocks by Hour
Overview
The Deadlocks by Hour report shows when deadlocks happen.
Deadlocks are rarely spread evenly. They cluster around the moment two particular code paths run at the same time – a nightly batch meeting the tail of the working day, two report jobs scheduled a minute apart, month-end processing colliding with routine writes. The hour a deadlock happens is very often the strongest clue to what it collided with.
Hours run down, days across, and each cell is one hour.
This report shows counts, not percentages. Most heat maps in the product normalise to a share of the busiest slot, because “how busy relative to the peak” is the useful reading. A deadlock count does not need normalising – three deadlocks is three deadlocks, and seeing the number matters more than seeing the proportion.
Where to find it
This report exists at two scopes:
- Instance – every deadlock recorded for the server, whichever database it happened in. Title: Deadlocks by Hour for <server name>.
- Database – scoped to one database. Title: Deadlocks by Hour for <database name>.
Both are historic reports; select the server or the database in the tree.
Reading the heat map
Each cell is one hour of one day, and the value is how many deadlocks were recorded in that hour. Darker means more.
The ramp is monotone in perceptual lightness, so the magnitude reads from lightness alone – in greyscale, on a projector, or under any form of colour vision deficiency. Cell text picks black or white per fill and clears 4.5:1 contrast against it.
Dark mode inverts the ramp’s anchor. Colour-blind mode uses a single blue hue with the same lightness steps.
No data is not zero
An hour where nothing was recorded is drawn differently from an hour with no deadlocks. On this page that matters a great deal: a collection gap and a clean hour look identical if both are painted as empty, and “we had no deadlocks” is a claim worth being sure about.
Clicking through
Click any cell to open the deadlock history for that hour – the graphs recorded then, with the statements on both sides.
The toolbar
| Button | What it does |
|---|---|
Show More |
Adds a week to the range. |
Show Less |
Removes a week. |
One to six weeks in one-week steps; the buttons hide at each end.
The range is shared with the other by-hour-by-day reports, so this map and the blocking one always cover the same window – which is the comparison that matters here, since deadlocks are contention that did not resolve itself.
Requirements
A historic report reading DeadlockHistory from the DBHealthHistory repository, populated by the collection service on a fifteen-minute timer.
Because collection is periodic, a deadlock is attributed to the hour it was recorded in. Deadlocks are captured after the fact, so a deadlock very near an hour boundary can land in the following cell.
Without collection configured there is nothing to draw. It works when the monitored server is unavailable.
How to read the report
- Look for the cluster. A single deadlock is life; a recurring cell is a design problem.
- Read the hour as a clue. What else runs then? That is usually the other half of the collision.
- Compare against Blocking by Hour by Day. Deadlocks are the visible tip of contention that was already there.
- Click into the worst cell and read the graphs.
- Then open Deadlock History to find out what keeps colliding – this page answers when.
- Widen the range before deciding a monthly pattern is real.
Common patterns
A dark cell at the same hour every weekday. Two scheduled things overlapping. Moving one by a few minutes is often the entire fix.
Deadlocks in the first hour of the working day. Batch work still finishing as users arrive.
A single dark column. One bad day – a release, a data load, a manual job. Click in and confirm.
Deadlocks spread evenly with no pattern. An access-order problem in the application rather than a scheduling collision. Deadlock History, in its Pairs view, is where that goes next.
A dark cell every month on the same date. Month-end. Predictable, and therefore schedulable.
Nothing anywhere, and empty rather than zero. Check that collection is actually running before concluding the instance is clean.
Related reports
| Report | Why you would go there |
|---|---|
| Deadlock History | What keeps colliding with what – this page answers when. |
| Deadlocks by Database | Which database is carrying the deadlocks. |
| Blocking by Hour by Day | The contention underneath, most of which never becomes a deadlock. |
| Blocking Tree | What is contending right now. |
Frequently asked questions
Why does this map show counts when the others show percentages? Because a deadlock count is already the number you want. Normalising three deadlocks to a share of the busiest hour would hide the only figure that matters.
How is this different from Deadlock History? This page answers when. That one answers what keeps colliding with what, which is the question whose answer is a fix. Use them together.
A deadlock happened at 10:59 but shows in the 11:00 cell. Deadlocks are captured after the fact by a periodic collector, so one near an hour boundary can land in the next cell.
What does a blank cell mean? Nothing was recorded for that hour – a collection gap, not a clean hour.
Is there a database-level version? Yes. The same report scoped to one database, from that database in the tree.