What’s the issue?
A SQL Server database can be in one of several states, including ONLINE, OFFLINE, RESTORING, RECOVERING, SUSPECT, and EMERGENCY. The OFFLINE state means the database has been deliberately taken offline by an administrator using ALTER DATABASE [DatabaseName] SET OFFLINE; and is not accessible to any users or applications.
This finding flags databases currently in the OFFLINE state, which warrants review to confirm the offline status is intentional and still appropriate. Unlike SUSPECT or RECOVERY_PENDING, the OFFLINE state is the result of a manual action rather than a failure.
Why is this a problem?
An offline database is completely unavailable, so any application, report, or process that depends on it will fail. While administrators sometimes take databases offline intentionally for maintenance, migration, or temporary isolation, an offline database that has been forgotten consumes storage and licensing without providing any value.
Forgotten offline databases also create operational risk. They are excluded from routine maintenance such as integrity checks, backups, and index maintenance, so when someone eventually brings them back online, they may have stale statistics, accumulated corruption that was never caught, or be missing transaction log data that prevents proper recovery.
Offline databases also clutter inventories and obscure the real state of the environment, making it harder to know which databases are truly needed and which can be retired.
What should you do about this?
Identify offline databases by querying sys.databases where state_desc = ‘OFFLINE’. For each one, work with application owners and the team that originally took it offline to determine the current intent: whether the database should be brought back online, archived and dropped, or left offline for a documented reason.
If the database is still needed, bring it back online with ALTER DATABASE [DatabaseName] SET ONLINE;, then run integrity checks, refresh statistics, and confirm backups are succeeding before declaring it healthy. If it is no longer needed, take a final backup for retention purposes, store it according to your data retention policy, and drop the database to reclaim resources.
For databases that must remain offline for a legitimate ongoing reason, document the reason, the owner, and the expected return to service or retirement date so they do not become orphaned.