The “Briefly unavailable for scheduled maintenance” message normally disappears when an update finishes. If it remains for more than a few minutes, the update probably stopped before WordPress removed its maintenance state.
The quickest fix is to disable maintenance mode, clear any cached copy of the page, and then check whether the interrupted update completed.
Use WP-CLI if you have SSH access
From the WordPress installation directory, check the current state:
wp maintenance-mode statusIf WP-CLI reports that maintenance mode is active, disable it:
wp maintenance-mode deactivateThen clear the WordPress object cache:
wp cache flushReload the site in a private browser window. If the maintenance message is gone, continue to the update check below rather than assuming the interrupted update completed successfully.
If WP-CLI says maintenance mode is already inactive, do not keep running the deactivate command. A page cache, CDN, or server cache may still be serving the old maintenance response.
Remove the .maintenance file manually
Use this method when WP-CLI is unavailable.
- Open the WordPress root directory with SFTP, SSH, or your hosting file manager.
- Find the file named
.maintenance. - Delete only that file.
- Reload the site and clear any active cache layers.
The WordPress root is the directory containing files such as wp-config.php, wp-load.php, and wp-settings.php.
Do not delete WordPress core folders, plugins, themes, or wp-config.php. The stuck message usually requires removing only .maintenance.
If hidden files are not visible in your hosting file manager, enable its option to show hidden files or dotfiles.
Clear every cache that can preserve the message
Removing maintenance mode does not necessarily remove a cached maintenance page. Clear the layers used by your site:
- WordPress page-cache plugin
- persistent object cache such as Redis or Memcached
- hosting control-panel cache
- CDN cache
- Nginx FastCGI, Varnish, or LiteSpeed server cache
- browser cache
Test from a private window after purging the caches. If possible, also check the site from a different network or use a direct origin URL to rule out the CDN.
Check the interrupted update
Getting the site back online does not prove that the original update finished.
Open Dashboard > Updates and check the item that was being updated. If it is still pending, take a backup and run that update again. Update one plugin or theme at a time if several updates were interrupted.
If the same update fails again, check these common causes before retrying:
- insufficient disk space
- PHP timeout or memory limits
- file ownership or permissions problems
- a security rule blocking update requests
- a network interruption while downloading the package
- an update process running in another browser tab or deployment job
Avoid repeatedly starting the same update without checking the error logs. A recurring failure needs its underlying cause fixed.
If the maintenance page is replaced by an error
A fatal error, blank page, or HTTP 500 after removing .maintenance usually means the interrupted update left a plugin, theme, or core files in an inconsistent state.
Start with the component that was being updated. If it was a plugin and you have WP-CLI access, confirm its status:
wp plugin status plugin-slugFor a theme:
wp theme status theme-slugReview the PHP error log before disabling multiple components. If one plugin caused the failure, isolate or roll back that plugin instead of deactivating everything.
Restore a known-good backup when files are missing, the update cannot be completed safely, or the site remains unusable after the affected component is isolated.
Prevent it happening again
Before large core, plugin, or theme updates:
- take a current backup
- confirm there is enough free disk space
- update business-critical sites in staging first
- avoid updating many large extensions in one batch
- keep the update tab open until WordPress reports completion
- monitor PHP and server logs during problematic updates
The maintenance message itself is usually easy to remove. The important part is verifying the interrupted update afterward so the site is not left in a partially updated state.