SyteLine SSRS report errors and slow reports: how to read the SSRS execution log

If you're chasing one specific failure, start with the report processing error guide. This guide is about using the log to find patterns: which reports fail, which are slow, and why.

A note on direction: Infor now describes custom SSRS reports as deprecated (still supported) and recommends Report-type forms or DataView-based reports for new custom reports. The execution log is still the best tool for keeping your existing SSRS reports healthy, and for deciding which ones are worth rebuilding. See SyteLine reporting options.

Step 0: Check your reports actually go through a report server

SyteLine installations differ in how reports are rendered. Before relying on this log, run a SyteLine report and check that a matching row appears (Step 2). If no row appears, your reports aren't going through an SSRS report server. Use the WAITING / no PDF checklist and Background Task History instead.

Step 1: Find the report server database

The SSRS report server stores its catalogue and log in a database usually named ReportServer (or ReportServer$InstanceName for a named instance). Your DBA can confirm the name in Report Server Configuration Manager under Database.

You need read access to that database. Treat it as sensitive, because the log contains report parameters, which can include customer numbers or other business data.

Step 2: Query the execution log

ExecutionLog3 is a view Microsoft provides for exactly this purpose. This read-only query lists the last day's failures:

-- failed report runs in the last 24 hours (read-only)
USE ReportServer;   -- your report server database name

SELECT  TimeStart,
        ItemPath,          -- which report
        UserName,
        Status,            -- rsSuccess = OK; anything else = problem
        Parameters,
        Format,            -- PDF, EXCELOPENXML, etc.
        TimeDataRetrieval, -- milliseconds running the dataset queries
        TimeProcessing,    -- milliseconds grouping, sorting, calculating
        TimeRendering,     -- milliseconds producing the output file
        [RowCount],
        ByteCount
FROM    ExecutionLog3
WHERE   TimeStart >= DATEADD(day, -1, GETDATE())
  AND   Status <> 'rsSuccess'
ORDER BY TimeStart DESC;

Remove the Status <> 'rsSuccess' line to see every run, not just failures.

Step 3: Read the status

rsProcessingAborted on its own doesn't say why. For the full error, open the SSRS log files on the report server. They're in the report server's LogFiles folder, named ReportServerService_<date-time>.log. Search for the time of the failed run. The real error, such as a SQL error number, a timeout or a bad expression, is usually a few lines further down.

Step 4: Use the time split for slow reports

This is the most useful part of the log for performance work. Every run records where its time went:

Check RowCount too. A report returning 200,000 rows when the user needs 200 is a filter problem, not a tuning problem.

Step 5: Find patterns, not just single failures

Two read-only queries that are worth running once a month:

-- slowest reports over the last 30 days
SELECT  ItemPath,
        COUNT(*)                                        AS runs,
        AVG(TimeDataRetrieval + TimeProcessing + TimeRendering) / 1000 AS avg_seconds,
        MAX(TimeDataRetrieval + TimeProcessing + TimeRendering) / 1000 AS max_seconds
FROM    ExecutionLog3
WHERE   TimeStart >= DATEADD(day, -30, GETDATE())
GROUP BY ItemPath
ORDER BY avg_seconds DESC;

-- reports that fail most often
SELECT  ItemPath, Status, COUNT(*) AS occurrences
FROM    ExecutionLog3
WHERE   TimeStart >= DATEADD(day, -30, GETDATE())
  AND   Status <> 'rsSuccess'
GROUP BY ItemPath, Status
ORDER BY occurrences DESC;

The first list is your tuning backlog, in priority order. The second is your reliability backlog. Reports nobody has run in the last few months are candidates to retire. Reports that are both heavily used and constantly breaking are good candidates to rebuild as Report-type forms.

Good habits

• Keep the log long enough to be useful. SSRS trims the execution log after a set number of days (60 by default). Check the setting if you want longer history.
• Don't edit the report server database. Read it, never write to it.
• Write the run's numbers into the ticket. "AR aging: 340 s data retrieval, 4 s rendering" tells the next person exactly where to look.

FAQ

Where is the SSRS execution log?

In the report server's database, usually called ReportServer, in the view ExecutionLog3.

What does rsProcessingAborted mean?

The report failed while running. The detailed reason is in the SSRS log files (ReportServerService_*.log) at the same time as the failure.

How do I tell whether a slow SSRS report needs SQL tuning?

Compare TimeDataRetrieval with TimeProcessing and TimeRendering in ExecutionLog3. If data retrieval is the largest, tune the SQL.

Why don't my SyteLine reports appear in ExecutionLog3?

Your installation may not render them through an SSRS report server. Check Background Task History and the report output instead.