Which component(s) does this affect?
Problem Statement
Motivation
For instances that host SQL Server Reporting Services (or Power BI Report Server), the ExecutionLog3 view in the ReportServer database exposes per‑execution report performance and outcome that the current engine‑DMV collectors can't see. Most valuable: the timing breakdown (data retrieval vs processing vs rendering) for diagnosing slow reports, and Status for catching report failures. This fits the existing collector → DuckDB → tab → alert pattern.
What ExecutionLog3 provides
Per report execution: ReportPath, UserName, RequestType, Format, Source (Live/Cache/Snapshot/History/…), Status (rsSuccess or an error code), TimeStart, TimeEnd, TimeDataRetrieval, TimeProcessing, TimeRendering (ms), ByteCount, RowCount. Example:
TimeStart TimeEnd TimeDataRetrieval TimeProcessing TimeRendering Source Status ByteCount RowCount
2026-06-12 16:19:23.503 2026-06-12 16:19:24.427 648 62 185 Live rsSuccess 68072 340
Proposed Solution
- New optional collector (e.g. ssrs_execution_log), auto‑detected and skipped silently when no ReportServer DB/ExecutionLog3 view is present (same gating model as the Query Store collector). Handle DB naming variants: ReportServer, ReportServer$, and Power BI Report Server.
- Incremental collection by TimeStart (high‑volume; SSRS retains only ~ExecutionLogDaysKept days, default 60), storing to a DuckDB ssrs_execution_log table; let the tool retain longer than SSRS does.
- A "Reporting Services" tab (or a section under an existing tab) showing top/slowest reports, the data‑retrieval/processing/rendering split, cache‑vs‑live source mix, failures, and trends — with the per‑database column filter.
- Alerts on Status <> 'rsSuccess' ("Report Failure" metric) routed through the existing notification pipeline (tray/email/Teams/Slack), plus an optional "slow report" threshold on total duration or rendering time. Add a severity‑map entry so the webhook card isn't just the default INFO color.
Use Case
Two ways:
- having alerts when Status <> 'rsSuccess' will help me to check for issues before client reaching out
- having stats will help me to focus on optimizing heavily used slower reports
Alternatives Considered
No response
Additional Context
Permissions
Reading ExecutionLog3 needs SELECT on ReportServer.dbo.ExecutionLog3 (e.g. db_datareader on the ReportServer DB). The current monitoring grant set (VIEW SERVER STATE + CONNECT ANY DATABASE) lets the account connect but does not grant SELECT on a user view, so document this one extra grant and have the collector degrade gracefully (skip + surface "capture unavailable") if it's denied — don't fail the cycle.
Which component(s) does this affect?
Problem Statement
Motivation
For instances that host SQL Server Reporting Services (or Power BI Report Server), the ExecutionLog3 view in the ReportServer database exposes per‑execution report performance and outcome that the current engine‑DMV collectors can't see. Most valuable: the timing breakdown (data retrieval vs processing vs rendering) for diagnosing slow reports, and Status for catching report failures. This fits the existing collector → DuckDB → tab → alert pattern.
What ExecutionLog3 provides
Per report execution: ReportPath, UserName, RequestType, Format, Source (Live/Cache/Snapshot/History/…), Status (rsSuccess or an error code), TimeStart, TimeEnd, TimeDataRetrieval, TimeProcessing, TimeRendering (ms), ByteCount, RowCount. Example:
Proposed Solution
Use Case
Two ways:
Alternatives Considered
No response
Additional Context
Permissions
Reading ExecutionLog3 needs SELECT on ReportServer.dbo.ExecutionLog3 (e.g. db_datareader on the ReportServer DB). The current monitoring grant set (VIEW SERVER STATE + CONNECT ANY DATABASE) lets the account connect but does not grant SELECT on a user view, so document this one extra grant and have the collector degrade gracefully (skip + surface "capture unavailable") if it's denied — don't fail the cycle.