SSRS Can't Connect to Database: 3 Fixes in Order

Fix 1: The 30-Second Check — Is the SQL Server Service Running?

I know this seems too simple, but I've lost count of the times a reboot or a stopped service caused this. SSRS needs the SQL Server (MSSQLSERVER) service to be running on the database server. If you're using a named instance, it's SQL Server (InstanceName).

1. On the server hosting the report server database, open Services.msc.
2. Look for SQL Server (MSSQLSERVER) or your instance name. If it's not running, right-click and Start.
3. Also check SQL Server Agent — it's often needed for scheduled reports, but not strictly for the initial connection.
4. Now restart the Reporting Services service from the same list, or from the Reporting Services Configuration Manager.

If the service was stopped, that was probably it. Test your report URL. If not, move on.

Fix 2: The 5-Minute Fix — Repair the Database Connection in Reporting Services Configuration Manager

This is the most common culprit. The database connection string gets corrupted after a password change, a server rename, or a migration. The Reporting Services Configuration Manager (RSConfigTool) can fix it in a few clicks.

1. Open Reporting Services Configuration Manager (search for it in Start Menu if you can't find it). Connect to your SSRS instance.
2. Go to the Database tab. You'll see the current database name (usually ReportServer) and the connection status.
3. If the status is anything other than 'Connected', click Change Database.
4. Choose Choose an existing report server database and click Next.
5. Enter the correct SQL Server name and credentials. Use Windows Integrated Security if possible — it's easier to manage. If you must use SQL authentication, double-check the password hasn't expired.
6. Select the ReportServer database (and ReportServerTempDB will be selected automatically). Hit Next and finish.

This rewrites the connection string in the RSReportServer.config file. Restart the Reporting Services service after this. If you still see an error about permissions, go to the next fix.

Fix 3: The 15-Minute Fix — Rebuild Database Permissions and Service Account

This one's for when the connection string is correct but SSRS still can't talk to the database. I've seen this after a domain migration or when the service account password was reset. The report server service account needs db_owner on the ReportServer and ReportServerTempDB databases. Here's how to fix it manually.

Step 1: Identify the Service Account

Open Reporting Services Configuration Manager, go to Service Account. Note the account name (e.g., DOMAIN\svc-ssrs or NT SERVICE\ReportServer).

Step 2: Grant Database Permissions

Connect to your SQL Server instance using SQL Server Management Studio (SSMS) with a sysadmin account. Run this script, replacing 'YourDomain\YourServiceAccount' with the actual account:

USE [ReportServer]
GO
IF NOT EXISTS (SELECT * FROM sys.database_principals WHERE name = N'YourDomain\YourServiceAccount')
BEGIN
    CREATE USER [YourDomain\YourServiceAccount] FOR LOGIN [YourDomain\YourServiceAccount]
END
GO
EXEC sp_addrolemember N'db_owner', N'YourDomain\YourServiceAccount'
GO
USE [ReportServerTempDB]
GO
IF NOT EXISTS (SELECT * FROM sys.database_principals WHERE name = N'YourDomain\YourServiceAccount')
BEGIN
    CREATE USER [YourDomain\YourServiceAccount] FOR LOGIN [YourDomain\YourServiceAccount]
END
GO
EXEC sp_addrolemember N'db_owner', N'YourDomain\YourServiceAccount'
GO

Step 3: Verify the Database Encryption Key

If you restored the ReportServer database from another server, the encryption key will be broken. SSRS will refuse to connect. In RSConfigTool, go to Encryption Keys and click Restore if you have a backup, or Delete Encrypted Content if you don't. Deleting it will reset data sources and subscriptions — warn your users first.

After that, restart the Reporting Services service. This fix has saved me more than once after a DR drill.

If none of these work, check Windows Firewall (port 1433 for default SQL instance) and ensure the SQL Server Browser service is running (port 1434 UDP) for named instances. Also check that the SQL Server allows remote connections — it's off by default in some editions.

Still stuck? Post your error message in the comments, and I'll help you dig deeper.