See what your report server is actually doing.

The ReportServer catalog has the answers. Nobody queries it.

SSRS and PBIRS both keep a full record of every execution, subscription, permission, and data source in their own catalog database — but almost nobody looks at it directly, so the same questions get asked and re-answered by hand every time.

Without it	With ReportServerCheck
"Which reports are actually slow?" means writing a query from scratch	Execution timing and 12-month trend reports, ready to open
Permissions are scattered across folders with no single view	One report, searchable by user or by object
Nobody knows which reports still have working subscriptions	A subscription report, plus a recipient-centric view of who gets what
Dead reports sit in the catalog forever	An inactive-reports report — no executions in 6 months
Data source drift goes unnoticed until something breaks	A per-report data source and shared-dataset usage map

What it needs.

SQL Server	2016 or later, hosting the ReportServer catalog database
Reporting platform	SSRS 2016, 2017, 2019, or 2022 — or Power BI Report Server
Access to deploy	Content Manager role on the target SSRS/PBIRS instance
Access to run	Read access to the ReportServer catalog database (via the shared data source)
Dependencies	None — no PowerShell, no dbatools, no compiled code. It's report content, deployed and run like any other report

Twenty reports across six areas.

Every report runs a read-uncommitted query directly against the ReportServer catalog — the Catalog, ExecutionLog, Subscriptions, Users, and ConfigurationInfo tables — through a single shared data source.

Area	What it answers
Server configuration & health	What is this instance actually configured to do?
Report execution & performance	What ran, how long did it take, and what's trending worse?
Data sources & datasets	Which report depends on which connection, shared or embedded?
User access & permissions	Who can see what, and who's actually using it?
Caching & snapshots	Which reports run from cache or a scheduled snapshot?
Server inventory	What's in the catalog, and what's just taking up space?

Every report, and what it shows.

Report	Area	What it shows
Report Server Usage and Statistics	Configuration & health	Landing report — where this server's data actually lives
ReportConfiguration	Configuration & health	Every name/value setting in ConfigurationInfo
ReportExecution	Execution & performance	Full execution history for a report: date, user, status, format, parameters
ReportErrors	Execution & performance	Execution error log for a report: status, error time, user, run time
ReportExecutionTrend	Execution & performance	12-month trend of runs, average data/processing/rendering time, and error counts per report
ReportStatistics	Execution & performance	Per-report rollup — last run, average run time, average rows, success percentage
ReportTimingAnalysis	Execution & performance	Top 20 slowest and most-run reports in the last 7 days
ReportTOP20Reports	Execution & performance	The 20 most-executed reports by hit count
ReportReportsOnline	Execution & performance	Daily successful vs. unsuccessful execution trend
ReportDataSourceHealth	Data sources & datasets	Every data source, shared or embedded, extension type, and which reports use it
ReportDataSourceStatus	Data sources & datasets	Report-to-data-source mapping, one row per report
ReportSharedDatasets	Data sources & datasets	Shared dataset usage counter — which reports consume which shared dataset
ReportQueries	Data sources & datasets	Extracts the underlying SQL from inside each report's dataset definition
ReportPermission	Access & permissions	Security audit — search by user or by object, shows role assignments and scope
ReportUsers	Access & permissions	Full user catalog — user ID, SID, user type, authentication type
ReportTOP50User	Access & permissions	Top 50 users by execution count, last 6 months
ReportUserAccessCount	Access & permissions	Monthly unique-user access trend, 12 months
ReportCacheSnapshots	Caching & snapshots	Reports running from a snapshot or cache, with creation/modified dates
ReportInventory	Server inventory	The full report catalog — item ID, name, path, description, data source, subscriptions flag
ReportInactiveReports	Server inventory	Reports with no execution in the last 6 months — cleanup candidates
ReportSubscription	Server inventory	Subscription details per report, including last run status
ReportSubscriptionRecipients	Server inventory	Recipient-centric view of subscriptions — who actually receives what, and in which format

All reports carry a consistent dark theme with gradient headers and a powershelldba.de footer, so they read as a single suite inside the SSRS portal rather than a pile of unrelated files.

Three ways to get it onto a server.

Method	How
SSRSDeploymentTool (recommended)	Point the companion deployment tool at this folder as the source, connect to the target instance, and deploy in one click
Visual Studio	Open ReportServerCheck.sln as a Report Server Project, set the target server URL in project properties, and deploy from Solution Explorer
SSRS REST API v2.0	POST each .rdl, Base64-encoded, to /api/v2.0/Reports — for scripting a deployment outside either tool

ReportServerCheck and SSRS Deployment Tool are a deliberate pair: one pushes report content onto SSRS or PBIRS, the other is report content — a diagnostic pack that, once deployed, lets you inspect that same instance's health, execution history, and permissions from inside its own portal.

Why it's built this way.

Data access

Every report uses one shared data source, ds_ReportServer, pointed at the ReportServer catalog database with Windows integrated security. Queries run under READ UNCOMMITTED isolation, so pulling execution history or permission data doesn't compete with SSRS's own catalog writes.

Reading inside the RDL format itself

Two reports go a step further than querying tables directly. ReportQueries parses the RDL XML stored in the catalog's Content column to extract each report's underlying SQL. ReportSubscriptionRecipients parses a subscription's ExtensionSettings XML to pull out the actual "To" email addresses, rather than just showing that a subscription exists.

No moving parts

There's nothing to install beyond the reports themselves — no service, no scheduled task, no PowerShell module. Once deployed, they're subject to the same security, caching, and subscription behavior as any other report on the server.

Free to use.

ReportServerCheck is released under the MIT License — no trial, no activation, no machine-bound license. Unlike some other tools in this suite, it's free and open, same as the PowerShell modules.

Get SSRS running first, then deploy the reports.

ReportServerCheck reads an existing Reporting Services instance — it doesn't set one up. These are the natural steps before and after deploying it.