Job History
Overview
The Job History report lays out every SQL Agent job run for one day against the clock.
A list of job outcomes tells you what failed. A timeline tells you something a list cannot: what was running at the same time as what. Two jobs that each take twenty minutes are fine, and the same two jobs overlapping on a Sunday night are a different story.
The page answers three questions:
- What ran, and when. Position and length on the timeline.
- What failed, and on which step. The grid drills into the steps of a run.
- What overlapped. Vertical alignment on the timeline is the whole point of the shape.
Where to find it
| Route | How |
|---|---|
| Server tree | Right-click the server → Instance Reports → Job History |
The page title reads Job History for <server name>.
Requirements
- Access to
msdb, which is where SQL Agent writes its history. Membership ofSQLAgentReaderRoleor equivalent is enough to read other people’s jobs; without it you see only your own. - SQL Agent has to be installed and have run. Express editions have no Agent, so there is nothing to show.
Nothing is installed on the monitored instance and nothing is written.
Reading the timeline
Each job run is a bar, positioned by start time and sized by duration, coloured by outcome.
| Outcome | Meaning |
|---|---|
| Succeeded | The run completed. |
| Failed | The run failed. The grid says which step. |
| Canceled | Somebody or something stopped it. |
| Retry | A step failed and was retried under its retry policy. |
The counts for all four are shown for the day, so the timeline always has a total behind it.
Retry is its own outcome rather than being folded into failure. A step that failed and succeeded on retry is a different operational fact from one that failed outright, and a job that retries every night is telling you something even though it reports success.
Moving through days
| Control | What it does |
|---|---|
| < Prev Day | Step back one day. |
| Next Day > | Step forward one day. |
| Filter Jobs | Narrow the timeline to the jobs you care about. |
The page opens on today. One day at a time is deliberate: a timeline is only readable when the axis is short enough for a bar to have a meaningful width, and a week of job runs compressed onto one axis turns every overnight job into the same sliver.
Filter Jobs matters on instances with a lot of jobs. A busy Agent with fifty jobs produces a timeline nobody can read, and filtering to the maintenance jobs, or to one application’s jobs, puts the overlap question back within reach.
Reading the grid
| Column | What it is |
|---|---|
| Row | The run, in order. |
| Job Step | Which step of the job this row is. |
| Start | When the step started. |
| Duration | How long it took. |
| Outcome | Succeeded, failed, canceled or retried. |
The grid is per step. That is the difference between “the backup job failed” and “the backup job failed on step 3, the log backup, after the full backup succeeded”, which are the same row in most tools and two different mornings.
How to read the report
- Scan for colour first. Failures and cancellations are what you came for.
- Read the step, not the job. A multi-step job that fails on step 4 has already done steps 1 to 3, which changes what you need to rerun.
- Look at what overlaps a failure. A job that fails only when another one is running is a contention problem rather than a job problem.
- Watch the right-hand edge of your maintenance window. Jobs that used to finish inside it and now spill past are the ones that will fail later without ever changing.
- Step back through days when something is intermittent. One day proves nothing.
Common patterns
One job failing at the same time every night. Usually something else on the timeline at that moment. Look across, not down.
A maintenance window that has crept. Compare the same weekday across a few weeks with the day buttons. Growth is gradual and invisible day to day.
A job that succeeds but shows retries every run. It is failing and recovering. The success is real and so is the fragility.
A long bar with nothing else near it. Just a long job. Nothing here says that is wrong.
Nothing at all on a day. Either Agent was stopped, or msdb has trimmed that far back. See below.
Where the data comes from
msdb.dbo.sysjobhistory and sysjobs, which is where SQL Agent records what it did.
Agent trims its own history. The default is 1,000 rows overall and 100 rows per job, so a job that runs every few minutes can push a job that runs nightly out of history within days. If a day looks emptier than you expect, that is usually why rather than nothing having run. The limits are in SQL Agent properties, not in this report.
Nothing is stored by Database Health Monitor. This reads msdb live.
Related reports
| Report | Why you would go there |
|---|---|
| Failed Jobs | Just the failures, across the retention window, without the timeline. |
| Job Schedules | What is supposed to run and when, rather than what did. |
| Backup Status | Whether the backup jobs achieved anything, as opposed to whether they ran. |
| Blocking by Hour by Day | Whether an overnight job is what the blocking pattern is about. |
| CPU by Hour by Day | Whether the maintenance window is what the CPU shape is about. |
Frequently asked questions
Why only one day at a time? Because a timeline needs a short enough axis for a bar to have a readable width. A week compressed onto one axis makes every overnight job the same sliver, which loses exactly the overlap the chart exists to show.
A day looks empty. Did nothing run? Check msdb retention before concluding that. SQL Agent trims history to 1,000 rows overall and 100 per job by default, and a frequently running job pushes everything else out.
Why is the grid per step rather than per job? Because which step failed decides what you have to rerun. A backup job that failed after the full succeeded is a different problem from one that failed before it.
What counts as a retry? A step that failed and was retried under the step’s own retry policy. It is shown separately because a job that quietly retries every night is worth knowing about even though it reports success.
Why can I not see other people’s jobs? Reading job history for jobs you do not own needs SQLAgentReaderRole in msdb or equivalent.
How is this different from Failed Jobs? Failed Jobs answers what failed. This answers what ran, when, alongside what, and on which step it went wrong.