Recommended Free Tools
Delete the hidden .maintenance file from your WordPress root directory, then purge your site and CDN caches. WordPress normally removes this file when an update finishes; an interrupted update can leave it behind and keep every visitor on the maintenance screen. Back up the site before changing files, and investigate the failed update if the file returns.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
What the maintenance message means
“Briefly unavailable for scheduled maintenance” is WordPress’s maintenance-mode response. During a core, plugin or theme update, WordPress creates a hidden file named .maintenance in the site’s root folder. When the update completes, the file is removed automatically.
As an Amazon Associate I earn from qualifying purchases.
A timeout, exhausted PHP memory, lost connection or another interruption can stop the update after the file is created but before WordPress deletes it. The result is a site that appears stuck in maintenance mode even though no update is still running.
The file is not normally inside wp-admin or wp-content. It sits beside them in the installation root, usually a folder named public_html or www. That folder also contains files such as wp-activate.php and directories including wp-admin and wp-content.
Do this first: a safe recovery sequence
- Make a backup. Save a copy of the database and WordPress files if your host provides a backup tool. If the update damaged a core file, a backup gives you a recovery point before you continue.
- Confirm that you are in the WordPress root. Do not delete files from a parent directory or from a different site on the same hosting account.
- Reveal hidden files. Files beginning with a dot are commonly hidden by file managers and FTP clients.
- Delete only
.maintenance. Do not removewp-admin,wp-includes,wp-contentor other WordPress files as part of this fix. - Clear every cache layer. Purge any WordPress caching plugin and your CDN or proxy cache. A cached copy of the maintenance page can remain visible after the file is gone.
- Test the site and the dashboard. Check the home page, a representative post or page, the login screen and
/wp-admin/in a private browser window.
Ways to remove the hidden file
Choose the access method you already use. The underlying fix is the same: remove .maintenance from the correct WordPress root folder.
| Method | What you need | Best fit | Main consideration |
|---|---|---|---|
| Hosting file manager | Access to your hosting control panel | Most accessible for site owners who do not use a terminal | Hidden-file display must be enabled before the file can be selected |
| FTP or SFTP | An FTP/SFTP account and client | Owners who already manage WordPress files remotely | The client may hide dotfiles until you force them to appear |
| SSH or WP-CLI | Shell access and, for WP-CLI, a working WordPress installation | Administrators who need the quickest direct operation | Running commands in the wrong directory can affect another site |
Using a hosting file manager
- Sign in to your hosting control panel and open its file manager.
- Open the site’s document root, commonly
public_htmlorwww. Identify it by the presence ofwp-admin,wp-contentandwp-activate.php. - Open the file-manager settings and enable Show Hidden Files or Show Hidden Files (dotfiles).
- Locate
.maintenancein that root directory. - Select it, choose Delete, and confirm. If the panel offers a trash folder, permanently remove the file or empty that trash so it cannot be restored accidentally.
- Visit the site in a private window. If the maintenance page still appears, purge the site and CDN caches before making further file changes.
Using FTP or SFTP
- Connect to the server with the account assigned to this WordPress installation.
- Browse to the directory containing
wp-admin,wp-contentandwp-activate.php. - In FileZilla, use Server > Force showing hidden files. Other clients have a similarly named option for dotfiles.
- Refresh the directory listing, select
.maintenance, and delete it. - Disconnect or leave the session open while you test the site, then clear caching layers if the old response remains.
Using SSH
SSH is appropriate when you can identify the document root confidently. After connecting, change to the directory that contains your WordPress files, list hidden files, and remove the flag:
Free tools Windows power users keep installed
One-click scans. No signup required.
cd /path/to/your/wordpress
ls -la
rm .maintenanceReplace the example path with the real document root supplied by your host. The ls -la step lets you verify that wp-admin, wp-content and .maintenance are in the directory before you run rm. If the file is absent, do not delete anything else; move to cache checks and troubleshooting.
Using WP-CLI
If WP-CLI is installed and you are in the WordPress root, run the maintenance-mode command provided by your installation. A successful deactivation removes the maintenance flag without requiring the web dashboard:
wp maintenance-mode deactivateWP-CLI must be able to load the site. If a fatal PHP error prevents it from starting, use the file-manager, FTP/SFTP or SSH method instead.
Clear caches after deleting .maintenance
Removing the file changes the server’s current state, but visitors may still receive a cached maintenance response. Purge each layer that can store HTML:
- WordPress cache: Open the caching plugin’s controls and use its purge or clear-cache action. Common examples include WP Rocket and LiteSpeed Cache.
- Host-level cache: Some managed hosts cache pages outside WordPress. Use the host’s purge control or ask support to flush it.
- CDN or reverse proxy: Purge the affected URL or the full cache in the CDN control panel. A CDN such as Cloudflare can continue serving the old maintenance page until its cache is cleared.
- Browser and network cache: Test in a private window or a different network after the server-side purge. This distinguishes a local cached response from a live server problem.
Do not treat a cached page as proof that .maintenance still exists. Check the file directly, purge the relevant caches, and then retest.
If the message returns immediately
A file that keeps reappearing means the update process is failing again. Deleting it repeatedly restores access only temporarily; it does not repair the update. Work through the likely failure points in order.
Rank #3
Check which update failed
Once the dashboard loads, open the update screen and note whether WordPress core, a plugin or a theme was being updated when the lockout began. Complete one update at a time so the failing component is identifiable. If the dashboard cannot load, inspect the hosting control panel’s task or error history and ask the host which update request was interrupted.
Consider PHP memory and execution limits
Memory exhaustion or a request timeout can stop an update before cleanup runs. Review the PHP error log and the memory or execution limits shown by your host. Raise a limit only within the host’s supported settings, or ask support to adjust it. A larger limit is useful only if the server has enough available memory; it will not fix a plugin conflict or damaged files.
Check permissions and storage
WordPress needs to write temporary and updated files, then remove the maintenance flag. Incorrect ownership or permissions can prevent either operation. Verify that the web server account can write to the WordPress files and that the account has available disk space. Have the host correct ownership or permissions when you are unsure of the server’s expected values; applying broad permissions recursively can create a security problem.
Test for a plugin conflict
If the message appears during a plugin update or returns after plugins load, deactivate the suspected plugin without the dashboard:
- Open
wp-content/pluginsthrough the file manager, FTP/SFTP or SSH. - Rename the suspected plugin’s folder, for example by adding
-disabledto its folder name. - WordPress will no longer find the original folder and will deactivate that plugin.
- Clear caches and test the site. If it works, restore the original folder name only after you have identified a compatible version or obtained a fix from the plugin’s developer.
Do not rename every plugin at once if you can avoid it. Isolating one component preserves useful evidence about the conflict.
Use debugging only while diagnosing
A PHP fatal error or an incomplete core file can leave the site locked. To expose the error, edit wp-config.php and enable WordPress debugging before the line that says to stop editing. A minimal temporary configuration is:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );With display disabled, visitors do not see the error details; review the generated debug log and the server’s PHP error log instead. Reproduce the failure once, record the component and error, then set WP_DEBUG back to false and remove temporary logging settings when diagnosis is complete. Leaving debugging enabled on a public site can expose sensitive information.
Repair an interrupted core update
If logs indicate a missing or corrupted WordPress core file, do not keep deleting .maintenance as a workaround. Restore the site from a known-good backup or replace the core files with a clean copy using your host’s supported WordPress reinstall process. Preserve wp-content and wp-config.php; those contain your content and configuration. Make another backup before replacing files, and use the same WordPress version unless you are deliberately performing an upgrade.
When the problem is not WordPress core
Some plugins implement their own maintenance or coming-soon screen. If deleting the root .maintenance file has no effect, inspect active plugins and their settings, then use the folder-rename test above to deactivate the suspected plugin. A plugin-generated screen can remain even though WordPress core is no longer in maintenance mode.
Also verify that you are editing the correct site. On shared hosting, several installations may have folders named public_html or www. The presence of the matching domain’s wp-content and configuration file helps distinguish the right root.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallHow to verify a complete recovery
- The root directory no longer contains
.maintenance. - The home page and an internal page load without the maintenance message.
- The WordPress login and dashboard open normally.
- The update screen no longer reports an unfinished operation.
- At least one private-window test succeeds after cache purges.
- Error logs do not show a new fatal error, memory exhaustion event or permission failure during the test.
After recovery, update the failed component separately and watch the site until the update finishes. If the file returns, stop and diagnose the underlying update failure instead of repeating the deletion.
Preventing another stuck update
- Keep current backups of both the database and files before updates.
- Run major updates one component at a time so a failure has a clear cause.
- Avoid closing the browser or interrupting a visibly active update request.
- Monitor available disk space and the PHP limits reported by your host.
- Keep plugins and themes compatible with the WordPress version you run.
- Remove temporary debugging settings after troubleshooting.
The maintenance flag is designed to be temporary. A single stale file is usually cleared by deleting .maintenance and purging caches; a recurring file is a diagnostic signal that the update environment needs attention.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
