Failed Jobs
Overview
The Failed Jobs report shows every SQL Server Agent job that failed on this instance, drawn as one lane per job with one tick per failed run against a shared time axis.
Two things make it more than a list of failures:
- The time axis. Job failures are rhythmic – nightly windows, retry storms, one job knocking over the next. Where the failures sit is usually the diagnosis.
- The denominator. The report fetches the successes as well as the failures, so it can say 14 of 14 runs rather than just 14, and it looks up the last successful run across the whole retained history rather than only the window.
Because every lane shares one axis, vertical alignment across lanes is an instance-wide event: three jobs failing in the same column at 01:00 is one cause, not three.
Where to find it
An instance-level report. Right-click the server → Instance Level Reports → Failed Jobs.
The Start Page’s Failed Jobs Last 24 Hours – All Instances tile is the same data across every registered instance, as a plain grid.
The toolbar
| Button | What it does |
|---|---|
| 24 hours / 7 days | The window. Remember that agent history is trimmed by row count, not by age. |
| Timeline | One tick per failed run on a shared axis. When did this start, and what else failed at the same moment? |
| Ranking | Failure-count bars with a caret at the previous window’s value. Is it getting worse? |
| Clock | A 24-hour dial, one self-scaled ring per job. Is this a schedule collision rather than a broken job? |
| Refresh | Re-reads msdb. There is no auto-refresh – job history only changes when a job runs. |
Switching views does not go back to the server. Every view is drawn from the failures already in hand.
Reading the grid
| Column | What it tells you |
|---|---|
| Job | The job name. The stripe on the lane above carries the same verdict. |
| Failures | Failed runs in the window, with a bar scaled against the worst job on screen. |
| Fail Rate | Failures out of total runs. One failure in 400 is not the same report as one in one. |
| Last Failure | How long ago, against the server’s clock. |
| Last Success | From the whole retained history, not just the window. not in history means msdb no longer holds a successful run – not that there has never been one. |
| Failing Step | The step that actually failed, matched to the run that failed. |
| Outcome | The step’s own error message where there is one, otherwise the job outcome message. |
| vs Previous Window | The change against the same length of time immediately before. Blank when this job’s history does not reach back that far. |
Double-click a row for the full outcome message. Double-click a tick on the chart for that exact run. Click a bar in the histogram to filter the grid to that hour or day.
How to read the report
- Start with the red stripes. A job whose most recent run failed is broken now, whatever its history says.
- Check the fail rate before the count. Ten failures out of two thousand runs is noise on a busy job; two out of two is a broken job.
- Read the last success. “It has not worked since Tuesday” is usually the most useful sentence on the page.
- Look down the chart, not just across it. Several lanes spiking in the same column is one cause – a server restart, a network blip, a maintenance window running long.
- Switch to Clock if the failures look scheduled. A solid block at 01:00 is a schedule collision; an even ring is something else entirely.
Common patterns
Every run failed, and it has not succeeded for days. The job is broken rather than flaky. The outcome message is usually enough to say why.
One failure in a long run of successes. Almost always transient – a linked server that was briefly unreachable, a lock timeout. The fail rate column is what tells you it is transient.
A tight column of failures across several lanes. One cause, not several. Something happened to the instance at that moment.
Failures every night at the same time, amber-tipped. The step is retrying and still failing. A nightly window that has grown past the time it is given looks exactly like this.
A job with a “Disabled” chip. The failures are from before it was turned off, or from someone starting it by hand.
“No history from before this window.” msdb trims job history per job – 100 rows a job out of the box – so a job that runs every minute can hold only hours of history on an instance that holds months. The report says so rather than reporting a trend it cannot support.
Related reports
| Report | Why you would go there |
|---|---|
| Job History | Every job on the instance laid out against the clock, failures and successes together. |
| Job Schedules | What is meant to run, and when. |
| Error Log | What SQL Server itself recorded at the moment of the failure. |
| Email Alert Log | Whether anyone was told. |
| Backup Status | When the failing job is a backup job, whether the backups actually happened. |
Frequently asked questions
Why does this show fewer rows than it used to? Because it now shows one row per job, not one per history record – and the query behind the old version returned each failure once per step of the job, so a five-step job with two failures arrived as ten rows.
Where did the Severity column go? sql_severity is 0 for an ordinary job failure. It was a column of zeros.
Where did the Instance Name column go? It was one value repeated down a single-instance page. It is still there on the Start Page’s all-instances view, where the rows really do come from different servers.
Why is 7 days the widest window? Because agent history is trimmed on a row count rather than by age, so on most instances a longer window would be a promise msdb cannot keep. When the window reaches past what is retained, the amber band says so.
Why does the chart show hours in one window and days in the other? A day-grained axis over a one-day window is a single bar, and an hour-grained axis over a week is a smear. The buckets follow the window.
What does the amber tick mean? The step retried and failed anyway, which is a different problem from a step that failed once.
Does the page refresh itself? No. Job history only changes when a job runs, so refreshing is a button rather than a timer.