When a scheduled report fails to arrive, run the report manually as the service account first, then check the ExecutionLog and ReportServer log files for the matching timestamp, confirm SMTP reachability and TLS settings, and verify the subscription owner and schedule status. Collect the failed run's exact timestamp before touching anything else, since that single detail lets you correlate ReportServer log files, ExecutionLog entries, and SMTP server logs in one pass.
TL;DR:
- Most subscription failures can be resolved by checking the last run status, manually running the report as the service account, and verifying the owner account and schedule.
- Logs in the ReportServer folder, database tables, and SMTP server reveal the root causes, especially when synchronized with UTC timestamps.
- Common issues include SMTP relay restrictions, TLS problems after Office 365 migration, permission issues with expired accounts, and timeouts related to report rendering or delivery.
- Data-driven subscriptions are prone to silent failures from bad recipient data or rate limiting, requiring targeted testing and log analysis of individual recipients.
- For large-scale or complex delivery needs, dedicated tools like PBRS support retries, batching, multiple formats, and better monitoring, making them preferable over native SSRS subscriptions.
Table of Contents
- Quick triage checklist: immediate checks that often fix or reveal the problem
- Where to look: logs and database tables with exact places and sample queries
- Common causes and targeted fixes: SMTP/TLS, auth, scheduling, timeouts, permissions
- Data-driven subscription gotchas and how to debug them
- How to test, reproduce and collect evidence for troubleshooting
- Monitoring, alerting and prevention to reduce recurrence
- ChristianSteven Software perspective: when to keep SSRS and when to adopt dedicated automation
- ChristianSteven Software solutions for subscription reliability
- FAQ
- Primary documentation and Q&A threads to verify commands
Quick triage checklist: immediate checks that often fix or reveal the problem
Before digging into logs, run through a short sequence that resolves a surprising share of subscription failures on its own.
- Open the SSRS web portal and check the subscription's last run status and error message.
- Query the ReportServer database for the subscription's row in the Subscriptions table to confirm it is active and has a valid OwnerID.
- Run the report manually, logged in as the SSRS service account rather than your own credentials, since permission differences between accounts cause a large share of "works for me" failures.
- Confirm the SQL Server Agent job tied to the subscription is enabled and ran at the expected time.
- Note the exact failure timestamp so you can pull matching entries from ExecutionLog and the ReportServer trace logs.
If the manual run succeeds but the scheduled run fails, the problem almost always sits in the owner account, the schedule, or the delivery path rather than the report itself.
Where to look: logs and database tables with exact places and sample queries
Most subscription failures leave a trail across three places: the file system, the ReportServer database, and the mail server.
- ReportServer trace logs live under the SSRS install path in a LogFiles folder, typically named
ReportServer__<timestamp>.log. - Raise the trace level to verbose (level 4) by editing the
ReportingServicesService.exe.configfile, then reproduce the failure and roll the level back, since verbose logs are large and meant to be temporary. - Query
ExecutionLog3or theExecutionLogStoragetable and inspectStatus,TimeStart,TimeEnd, andRequestTypeto see how the run actually behaved. - A simple starting query:
SELECT Status, TimeStart, TimeEnd, RequestType FROM ExecutionLogStorage WHERE TimeStart > DATEADD(day, -1, GETUTCDATE()) ORDER BY TimeStart DESC. - Check Windows Event Viewer and the SMTP server's own logs for rejection or authentication errors around the same window.
- Convert everything to UTC before comparing timestamps across the report server, the database, and the mail server, since local time zone drift is a common false lead.
Pro Tip: Capture verbose logs during a single reproduction run only, then turn the trace level back down, since leaving it on fills disk space fast on busy servers.
Microsoft's own troubleshooting guidance for subscriptions and delivery walks through these same log locations and lists the documented failure messages tied to expired schedules and mail server rejection, which makes it the right first stop when matching an error string.
Common causes and targeted fixes: SMTP/TLS, auth, scheduling, timeouts, permissions
Subscription failures cluster into a handful of repeat offenders, and most are fixable without touching the report definition itself.
- SMTP relay and sender rejection: check the mail server's response code and retry count; a rejected sender address or a relay restriction shows up clearly in the SMTP log.
- TLS negotiation after moving to Office 365: intermittent failures with the message "Authentication failed because the remote party has closed the transport stream" point to legacy TLS. Community reports tied to this exact error message were resolved by updating the .NET Framework and enabling TLS 1.2 with strong cryptography at the OS level.
- Authentication and sender allowlists: confirm SMTP AUTH is configured correctly and that the sending address is on the mail server's allowlist.
- Invalid subscription owner: an expired or disabled account breaks scheduled runs even though manual runs under your own account succeed. The fix is a direct update:
UPDATE Subscriptions SET OwnerID = (SELECT UserID FROM Users WHERE UserName = 'validaccount') WHERE SubscriptionID = '<id>'. - Processing timeouts: compare the manual run time against the scheduled run time; a report that renders in 20 seconds manually but times out on schedule usually needs a higher timeout setting or a leaner dataset.
- Schedule and agent issues: an expired schedule, an overlapping database cleanup job, or a Windows service restart during the scheduled window can all silently kill a run.
Intermittent delivery failures tied to TLS renegotiation after an Office 365 migration are a documented pattern in community troubleshooting threads, where Microsoft's progressive rejection of older TLS versions on SMTP AUTH connections caused failures that only appeared once systems moved off TLS 1.2. The practical fix stays the same across these threads: update the server's .NET Framework and set the strong cryptography registry keys so SSRS negotiates TLS 1.2 consistently.
Data-driven subscription gotchas and how to debug them
Data-driven subscriptions add a layer of failure modes that standard subscriptions never hit, because each recipient is a separate delivery attempt built from a query result.
- A single bad row, like a malformed or missing email address, can fail silently for one recipient while the rest of the batch delivers fine.
- Isolate the bad row by running the data-driven query alone and scanning the recipient column for blanks, typos, or duplicate semicolons.
- Large recipient lists can trigger SMTP throttling or rate limits on the mail server, which looks like random, unrelated failures.
- Test against a small subset of five or ten recipients first, then scale up, to confirm whether volume or a specific row is the actual cause.
- When capturing logs for a data-driven run, include the parameter payload and the row identifier in your notes, since the ExecutionLog entry alone will not tell you which recipient failed.
How to test, reproduce and collect evidence for troubleshooting
A clean reproduction is the fastest path to a fix, and it takes four steps.
- Run the report manually under the SSRS service account and record the render time for comparison against the scheduled run.
- Capture the email headers from a test send to check which TLS version and server response the mail server actually used.
- Turn on verbose logging for the reproduction window only, then roll the trace level back down afterward.
- Line up the ReportServer log, the ExecutionLog entry, and the SMTP log using the same UTC timestamp so the three sources describe the same event.
Pro Tip: Keep a single running document with timestamps, log excerpts, and the exact error string for each incident, since recurring failures almost always match a pattern you already solved once.
Our earlier piece on automated email reports that refuse to send covers this same reproduction workflow in more depth for readers who want the full walkthrough.
Monitoring, alerting and prevention to reduce recurrence
Catching a failure before a user notices a missing report beats troubleshooting after the fact.
- Schedule a recurring query against
ExecutionLogStoragethat flags any row whereLastStatus != 'rsSuccess'and route the result to an alert. - Set a separate alert for spikes in delivery failures or TLS handshake errors, since a sudden cluster usually points to a mail server or certificate change rather than the report itself.
- Move heavy transforms out of the report and into an ETL process upstream, which shortens render time and reduces timeout risk.
- Build retry logic and batching into the delivery process for large recipient lists instead of relying on a single attempt.
- Keep a runbook for each recurring failure type and retain logs long enough to support a post-incident review.
| Practice | What it catches | Where to apply it |
|---|---|---|
| ExecutionLog status query | Failed or aborted runs | SQL Server Agent job, scheduled daily |
| SMTP log alerting | TLS and authentication errors | Mail server or gateway |
| Retry and batching logic | Throttling on large recipient lists | Data-driven subscription delivery |
| Runbook and log retention | Repeat incidents | Post-incident review |
Tightening mail server security settings in line with guidance such as this Microsoft 365 security overview also reduces the odds that a security policy change on the mail side breaks subscriptions without warning.
ChristianSteven Software perspective: when to keep SSRS and when to adopt dedicated automation
Native SSRS subscriptions hold up well for a handful of recipients on a simple schedule. They start showing strain once recipient lists grow large, SMTP errors turn intermittent instead of consistent, or compliance requirements call for audited, secure delivery across multiple formats and destinations. At that point, retry logic, bursting, and centralized monitoring stop being nice extras and start being the difference between a reliable pipeline and a recurring fire drill.
— Christian Ofori-Boateng
ChristianSteven Software solutions for subscription reliability
We built PBRS for Power BI and SSRS to take over exactly the pain points this checklist walks through: a single scheduled job that fails silently, an owner account that expires, a recipient list that outgrows plain SMTP.
- Centralized retries and delivery status allow failed runs to be flagged and resent.
- Support for data-driven bursting and multiple output formats and destinations.
- The software is designed with compliance and audit requirements in mind.
If the checklist above is something your team runs every week, request a demo of PBRS and see what centralized subscription automation looks like for your SSRS reports.
FAQ
What does "rsProcessingAborted" mean in an SSRS subscription?
This status in the ExecutionLog usually means the report render or delivery step was interrupted before completion, often by a timeout or a mail server rejection. Check the ExecutionLogStorage entry for that run's TimeStart and TimeEnd and compare it against the mail server's log for the same window.
Why does a subscription fail only when run by the scheduler, not manually?
This pattern almost always points to the subscription's owner account rather than the report itself, since the scheduler runs under that stored owner's permissions instead of yours. Confirm the OwnerID in the Subscriptions table points to an active, valid account and update it if the original owner's credentials expired.
How do I fix intermittent SSRS email failures after moving to Office 365?
Intermittent failures after an Office 365 migration are frequently caused by legacy TLS negotiation rather than a credentials problem. Updating the .NET Framework and enabling TLS 1.2 with strong cryptography at the OS level resolves this pattern in documented community cases.
What is the fastest way to find the exact cause of a failed subscription?
Start with the ExecutionLogStorage table filtered to the failed run's timestamp, then pull the matching ReportServer trace log for the same window. Running the report manually as the SSRS service account immediately afterward usually confirms whether the issue sits in the report, the schedule, or the mail delivery step.
Should a growing organization replace native SSRS subscriptions?
Native subscriptions work fine at small scale, but large recipient lists, frequent intermittent SMTP errors, or compliance needs are signs it is worth adding dedicated automation like PBRS for Power BI and SSRS on top of SSRS rather than replacing it outright.
Primary documentation and Q&A threads to verify commands
- Troubleshoot Reporting Services subscriptions and delivery
- Stack Overflow: SSRS troubleshooting threads
- Microsoft 365 security practices