What’s the issue?
Always On Availability Groups include an automatic page repair feature that detects certain kinds of page corruption and attempts to fix them by requesting a clean copy of the affected page from another replica. The feature covers specific corruption types including checksum failures, torn pages, and I/O errors 823 and 824, and it operates transparently while the AG continues running.
Each repair attempt is recorded in sys.dm_hadr_auto_page_repair, which captures the database, the page ID, the error type, the time of the attempt, and the resulting state. States include QUEUED, REQUESTED, PENDING, MODIFIED, IRREPARABLE, and REPAIRED, with REPAIRED indicating the page was successfully rebuilt from the partner replica.
This finding identifies AGs where one or more databases have had automatic page repair attempts recorded recently on a replica.
Why is this a problem?
The self-healing behavior is genuinely valuable, since it corrects corruption without requiring a restore or manual intervention. However, the presence of repair attempts is a strong signal that the storage subsystem on the affected replica is failing or beginning to fail. Automatic page repair fixes the symptom, not the cause.
Corruption almost always originates below SQL Server, in the storage subsystem, disk controllers, drivers, or memory. A repair attempt means a page was read and found to be invalid, which indicates the underlying storage returned bad data. Storage that produces one corrupt page will typically produce more, and the rate often accelerates as hardware degrades further.
The repair mechanism also has limits. It only covers specific corruption types, it requires a healthy partner replica with a clean copy of the page, and it cannot repair pages in certain critical structures. Corruption that falls outside the covered scenarios, or that occurs when no clean copy is available, produces attempts that end in IRREPARABLE state and require conventional recovery from backup.
What should you do about this?
Review the repair history by querying sys.dm_hadr_auto_page_repair on each replica, capturing the affected databases, page IDs, error types, timestamps, and final states. Confirm that each attempt reached the REPAIRED state, and treat any attempts in IRREPARABLE state as requiring immediate conventional recovery from a clean backup.
Run DBCC CHECKDB on the affected databases on the replica where the repairs occurred, to confirm no additional corruption exists beyond what automatic page repair addressed. Run it on the other replicas as well, since the corruption may indicate an issue that affects more than one instance if they share storage infrastructure.
Investigate the storage subsystem on the affected replica with the storage and infrastructure teams. Review Windows event logs for disk and controller errors, check storage vendor diagnostics and firmware levels, run memory diagnostics, and look for patterns in when the corruption occurred. Corruption almost always recurs if the root cause is not addressed.
Add automatic page repair monitoring to your standard AG health check and alerting process so future attempts are detected immediately. Pair this with regular DBCC CHECKDB runs, backup checksum default enabled, and page verification set to CHECKSUM on all databases, so corruption is caught as early as possible regardless of which mechanism detects it first.