What’s the issue?
Many SQL Server configuration options can be changed at runtime using sp_configure followed by RECONFIGURE, but some settings only take full effect after the SQL Server service is restarted. When a change has been made but the service has not yet been restarted, the option shows different values for value (the configured value) and value_in_use (the value currently in effect) in the sys.configurations system view.This finding identifies instances where one or more configuration options have a pending change waiting on a service restart. Common examples include max worker threads, min server memory, max server memory, network packet size, and certain advanced settings.
The condition can persist for weeks or months when changes are made but a restart is not scheduled promptly, leaving the instance in a state where the configured intent does not match the actual running behavior.
Why is this a problem?
The most immediate issue is that the intended configuration change is not actually in effect. Whoever made the change believes the new value is active, while the instance continues to behave according to the previous setting. This creates a gap between documented configuration and actual behavior that can mislead troubleshooting and tuning efforts.The condition also creates risk during the next service restart, whether scheduled or unplanned. A restart that occurs unexpectedly (due to patching, host failover, or service crash) will activate the pending change at an unpredictable time, potentially during peak business hours and without the team being prepared for any side effects. If the change turns out to be incorrect or causes problems, the issue surfaces in the worst possible context.
Pending changes also accumulate. When multiple changes are made over time without a restart, the instance carries an increasing list of differences between configured and active values, making it harder to know which change is responsible if behavior shifts after the eventual restart.
What should you do about this?
Identify pending changes by querying sys.configurations and looking for rows where value <> value_in_use. Review each pending change with the team or individual who made it to confirm the intent is still correct and that the change should be activated.For changes that are correct and ready to take effect, schedule a service restart during an appropriate maintenance window. Communicate the restart to application owners, confirm backups are current, and have a rollback plan in place in case the change causes unexpected behavior. After the restart, verify the configuration is now active by re querying sys.configurations and confirming value and value_in_use match.
For changes that should be rolled back rather than activated, set the option back to its previous value with sp_configure and run RECONFIGURE so the configured value matches the running value again. This avoids accidentally activating an unwanted change at the next restart.