SSRS Failed Executions
Overview
SSRS Failed Executions shows the runs on a SQL Server Reporting Services instance that did not work, and what the report server said about each of them.
The execution log records a status string for every run. SSRS Report Speed counts the ones that were not rsSuccess; this page shows them. On a real report server the same handful of failures repeats hundreds of times, so the rows are grouped by report and status, and the list of distinct problems is usually short.
Three distinctions decide which rows matter:
- Failed is not aborted. A status containing
AbortorCancelis a reader navigating away or a timeout somebody configured, not a broken report. Those are counted separately and drawn in amber rather than red. - A failure nobody saw is worse. A failure on a subscription run was not reported by anyone, and it will happen again on the same schedule. Those are counted in their own column.
- Always failing is not the same as sometimes failing. A report that fails on every run in the window is broken; one that fails one run in fifty is usually a timeout under load or one bad parameter value.
Where to find it
Only shown for a database holding a Reporting Services catalog.
- Tree: expand the report server database, then Real Time > SSRS > Failed Executions.
- Server Configuration: press Failed runs on the toolbar of SSRS Server Configuration, or choose What has been failing from its right click menu.
Requirements
- A Reporting Services catalog database, normally called
ReportServer. The SSRS pages are offered whendbo.ExecutionLoganddbo.Catalogboth exist in the database being looked at. SELECTondbo.ExecutionLogordbo.ExecutionLog3,dbo.ExecutionLogStorage,dbo.Cataloganddbo.ConfigurationInfo.dbo.ExecutionLog3is used when the report server has it, SSRS 2008 R2 and newer. The originaldbo.ExecutionLogview is used otherwise, from the same query.
The three views
The toolbar switches between By report, By status and By person. All three are drawn from what the page read when it loaded, so switching does not go back to the server.
By report
One bar per report, labeled with the report name and its folder underneath.
By status
One bar per distinct status string, such as rsProcessingAborted, with Failed or Aborted underneath. This is usually the most useful of the three: the distinct list of things that have gone wrong is short, and it is the list somebody acts on.
By person
One bar per account, counting only that account’s own failed runs. The page reads the failures a second time grouped by account as well as by report and status, so a failure several people hit is split between them rather than credited to one name.
Reading the bars
| Mark | Meaning |
|---|---|
| Red bar | The group contains at least one real failure |
| Amber bar | Every run in the group was aborted or canceled |
| Amber outline | At least one of the group’s failures was a subscription run |
The value on the right is the number of failed runs. Hover over a bar for the group’s total and how many of those runs were subscriptions.
The chart draws the top of the ranking. When there are more groups than fit, the line under the plot says how many are shown out of how many, and the grid holds every row.
Reading the grid
| Column | What it holds |
|---|---|
| Report | The report’s catalog path, or (report deleted) |
| Status | The status string the report server recorded, in red when it is a real failure |
| Outcome | Failed or Aborted |
| Times | How many runs of this report ended with this status |
| Of runs | How many times this report ran, counted the same way as Times |
| Rate | Times as a share of runs, or – when there is no total |
| Unattended | How many of those runs were subscription runs |
| Last time | When this report last ended with this status |
| Who | The first account recorded, and how many others it happened to |
| Notes | What the page derived about the row |
The Notes column says, where it applies:
- that the row was aborted rather than failed
- that every run of the report in the window ended this way, so it is broken rather than unreliable
- that it fails less than a fifth of the time, which usually means a timeout under load or one bad parameter value
- how many of the failures were subscription runs
- how many people it has happened to, when that is more than three
Findings
The headline counts the failed runs, the reports they span and the distinct statuses, plus how many runs were aborted rather than failed. The line under it adds, where they apply:
- The most common failure, naming the status, the report and how many times.
- How many failures were subscription runs, so nobody was there to see them.
- How many reports have failed on every run in the window.
- That aborted is not failed, and is drawn in amber.
- How many days the execution log keeps, because every count here is bounded by that.
Actions
- Click a bar to select the group’s row with the most failures in the grid. In the By person view that is the report and status pairing the person hit most.
- Double click a bar to select every grid row the group covers.
- Right click a bar for the grid’s right click menu on the row a click selects.
- Right click a row for Copy report path, Copy the status, Open Report Speed (opens SSRS Report Speed), Open Subscriptions (shown only when some of the row’s failures were subscription runs, and opens SSRS Subscriptions) and Go to its data sources (opens SSRS Data Sources with this report’s rows selected). Every one lists the whole server; only Data Sources lands on the row’s report.
- Right click an empty part of the chart to copy the chart to the clipboard.
- The toolbar buttons Report speed, Subscriptions and Data sources open those pages for the same report server.
Where the data comes from
dbo.ExecutionLog3 when the report server has it, otherwise dbo.ExecutionLog, joined to dbo.Catalog, grouped by report path, report name and status, and filtered to every status that is not rsSuccess. A second read groups the same failures by account, report and status for the By person view.
Three details worth knowing:
- The filter is “not
rsSuccess” rather than a list of failure strings. The list ofrsstatus values differs between versions and grows, and a page that enumerates them would silently drop the one nobody had seen before. - A run counts as a subscription run when its request type starts with
Sub. On the original view, where request type is a number, anything other than 0 is a subscription. - On SSRS 2008 R2 and newer, only rows whose item action is
Renderare counted, so sort, bookmark and drillthrough round trips do not inflate the count. The Of runs total is counted the same way, through the same view with the same filter, which is also how SSRS Report Speed counts runs, so Rate compares like with like.
Messages you may see
Nothing has failed on this report server. Every run recorded in the execution log ended in rsSuccess. On a server people use, check SSRS Server Configuration: an execution log that is switched off, or one that keeps nothing, produces exactly this page.
The report server query did not finish in time. The execution log on a busy report server can hold millions of rows. Press F5 to try again.
Related reports
- SSRS Report Speed – what the same reports cost when they do work
- SSRS Reports Run – individual executions over the last twenty four hours
- SSRS Subscriptions – the schedules behind the unattended failures
- SSRS Delivery History – whether the deliveries themselves worked
- SSRS Data Sources – what the failing reports connect to
- SSRS Server Configuration – the execution log settings
Frequently asked questions
Why is rsProcessingAborted amber when the report did not finish? Any status containing Abort or Cancel is treated as aborted rather than failed. That is usually a reader who navigated away or a timeout that was set on purpose, which is a different problem from a report that is broken.
What does the Unattended column add? It counts the failures that happened on a subscription run. Nobody was looking at the screen when those failed, so nobody reported them, and they will fail again the next time the schedule fires.
How far back does this page look? As far back as the execution log keeps, which is the ExecutionLogDaysKept setting and defaults to 60 days. The line under the headline states the value this server uses.