WordPress Stuck in Maintenance Mode: Delete .maintenance and Fix the Update

You updated a plugin, a theme or WordPress itself, and now every page says:

Briefly unavailable for scheduled maintenance. Check back in a minute.

A minute passes, then ten, and the message is still there. The site is stuck in maintenance mode. It is one of the most common WordPress problems, and one of the easiest to fix, usually in under five minutes.

Why it happens

When WordPress runs an update, it creates a file named .maintenance in the site root (the same folder as wp-config.php). While that file exists and is recent, WordPress shows the maintenance message to visitors instead of loading the site. When the update finishes, WordPress deletes the file.

If the update is interrupted, the file stays behind. Typical reasons:

• You closed the browser tab or lost the connection during a bulk update.
• PHP ran out of time or memory partway through (see memory limit exhausted).
• Many plugins were updated at once, and one of them failed.
• The server restarted, the host killed a long process, or the disk filled up.
• A security or caching layer blocked the request that was finishing the update.

The file is just a flag. The usual cure is to delete it, then check that the update really completed.

What the file contains

The .maintenance file is a tiny PHP file holding a timestamp:

<?php $upgrading = 1759650000; ?>

WordPress compares that Unix timestamp to the current time. If the timestamp is more than about 10 minutes old, WordPress ignores it and the site starts loading again without you doing anything. So if you have waited more than 10 minutes and the site is still down, either the file's timestamp is recent because something keeps recreating it, or the problem is something else entirely, such as a fatal error left by a half-finished update.

Step 1: Confirm it is maintenance mode

Check what your server returns with the HTTP Status Checker. WordPress's maintenance page is served with HTTP 503 (Service Unavailable) and a Retry-After header. You can see this from the command line:

curl -sI https://example.com/ | head -n 8

A 503 with the text above confirms it. A 503 from something else, such as an overloaded server, looks different; see fix 503 Service Unavailable. The Maintenance Detector can also tell whether a site is serving a maintenance page.

Step 2: Delete the .maintenance file

The file is hidden because its name starts with a dot. Enable "show hidden files" in your tool.

SFTP or the host's file manager:

1. Go to the folder that contains wp-config.php, wp-content and wp-admin. On most hosts this is public_html, www or htdocs.
2. Show hidden files (in cPanel File Manager, Settings, "Show Hidden Files (dotfiles)").
3. Delete .maintenance.

SSH:

cd /var/www/html
ls -la .maintenance
rm .maintenance

WP-CLI:

wp maintenance-mode status
wp maintenance-mode deactivate

wp maintenance-mode deactivate removes the file for you. Reload the site, using a private window if needed, since your browser or a page cache plugin may still show the old message. Purge the page cache and CDN too.

Step 3: Find out whether the update finished

The site is back, but the update that failed may be half done. Check the state before you do anything else.

wp core version
wp core verify-checksums
wp plugin list --fields=name,status,version,update
wp theme list --fields=name,status,version,update
wp core update-db

Interpretations:

• Core update interrupted. wp core verify-checksums reports missing or modified files, and the dashboard may ask for a database upgrade. Re-run the core update: wp core update --force (replaces core files and leaves wp-content alone), then wp core update-db.
• Plugin update interrupted. The plugin folder can be incomplete or even missing, and WordPress may have deactivated the plugin. Reinstall it: wp plugin install plugin-slug --force --activate. If it is a premium plugin, upload a fresh copy from the vendor.
• Theme update interrupted. Reinstall the theme the same way: wp theme install theme-slug --force.
• Leftover upgrade folder. Check wp-content/upgrade/ for leftover directories from a failed update; it is safe to remove their contents after the update has been redone, because it is temporary working space.

Then log in to the dashboard, check Dashboard, Updates for anything pending, and test the key pages of the site.

Step 4: If the site is still down after deleting the file

If deleting .maintenance did not help, or it reappears, look at these:

1. The file comes back. Something is still running an update. A bulk update may be going on in another browser tab, WP-CLI session or cron job. Wait for it to finish, or check wp cron event list for update-related events, and look at whether automatic background updates are running. If the file reappears repeatedly, a plugin or a management tool (such as a multi-site manager) is retrying a failing update; deactivate it.
2. A different message or a white screen. The update left broken code. Enable debug logging and read wp-content/debug.log; see WordPress white screen of death. If a plugin is named, disable it by renaming its folder, as described in plugin conflict troubleshooting.
3. A cached page. The message may come from a cache layer. Purge the caching plugin, server cache and CDN. Check the HTTP Header Checker for Age or a cache status header, to see if the response comes from a cache.
4. A maintenance plugin is active. Plugins that offer "coming soon" or "maintenance mode" pages produce a similar page, but they are controlled from their own settings, not through .maintenance. Disable the plugin from the dashboard, WP-CLI or by renaming the folder. Their pages sometimes return a 200 rather than 503, which is bad for SEO.
5. The host's own maintenance page. Some hosts put a static page in front of the site during server work. Ask support if the page does not mention WordPress.
6. Wrong file location. On multisite or when WordPress lives in a subdirectory, check that you are deleting .maintenance in the folder that holds wp-config.php for that install. The ABSPATH folder is the one WordPress checks.
7. Permissions. If you cannot delete the file because of ownership, use SSH with sudo (sudo rm .maintenance), or ask the host to fix file ownership. Wrong ownership is also a frequent cause of failed updates, since WordPress could not write the files it needed.

Step 5: Fix the cause of the failed update

If one update failed, another will unless you deal with the underlying issue.

• Check disk space and inodes: df -h and df -i. A full disk is a classic cause of aborted updates.
• Check PHP limits. Updates need enough max_execution_time and memory. Large plugin updates through the web interface can hit them.
• Check file permissions and ownership. WordPress needs write access to wp-content and the root folder for core updates. If WordPress asks for FTP credentials when you update, ownership is wrong.
• Update one at a time. Bulk updates are more likely to be interrupted, and when something breaks you do not know which update did it. For critical sites, update on staging first.
• Prefer WP-CLI for updates: it does not depend on browser sessions or the web server's time limits.

wp plugin update --all
wp theme update --all
wp core update

• Back up before updating, so a bad update can be rolled back.
• Do not close the tab during an update, and do not interrupt it unless you are sure it has hung.

Do it the right way next time: planned maintenance

WordPress's automatic maintenance page is meant to last seconds. For planned work that lasts longer, such as a migration or redesign, use a controlled approach: serve a static page with a 503 status and a Retry-After header so that search engines understand the downtime is temporary. See website maintenance mode done right. If you use an external monitor, schedule a maintenance window beforehand so no false alerts fire.

Monitor for this problem

A site stuck in maintenance mode can sit like that for hours, particularly after an automatic update at night. An uptime monitor checks every few minutes and alerts you on a 503, so you can delete the file within minutes instead of finding out from a customer. Add a keyword check for text that should appear on your home page for extra safety.

Next steps

• Confirm what the site returns with the HTTP Status Checker.
• Check for maintenance pages with the Maintenance Detector.
• Set up alerts in the uptime monitor.
• Read website maintenance mode done right.
• Read WordPress plugin conflict troubleshooting.

FAQ

Is it safe to delete the .maintenance file?

Yes. It is only a flag file that WordPress creates during updates and removes afterward. Deleting it does not harm your content, though you should check that the interrupted update completed properly.

I cannot see the .maintenance file. Where is it?

It is a hidden file in the same folder as wp-config.php. Turn on "show hidden files" in your FTP client or hosting file manager, or list it over SSH with ls -la.

Will the site fix itself if I wait?

Often, yes. WordPress ignores a .maintenance file that is older than about ten minutes, so the site should come back by itself. If it does not, something is recreating the file or another problem is present.

Does maintenance mode hurt SEO?

A short 503 is harmless, and search engines treat it as temporary. A maintenance page that stays up for days can lead to crawling problems and dropped pages, so fix it quickly. See website downtime SEO impact.

Can I put my own site into maintenance mode on purpose?

Yes. wp maintenance-mode activate and wp maintenance-mode deactivate toggle WordPress's built-in page. For longer work, use a dedicated 503 page or a maintenance plugin that sends the right status.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.