How to fix WordPress stuck in maintenance mode

You clicked Update on a plugin, the spinner kept going, and the page never came back. Now the site says “Briefly unavailable for scheduled maintenance. Check back in a minute.” The minute has turned into twenty, and visitors see the same message.

WordPress puts the site into maintenance mode on purpose during every core, plugin and theme update. It writes a hidden file called .maintenance to the installation root and deletes it when the update finishes. If the update is interrupted or fails, the file can be left behind. Removing it is the standard fix. The steps around that are what decide whether you get a working site or a half-updated one. If the update itself failed with an error, our guide to recovering from a failed WordPress update covers the full recovery order.

Which maintenance page are you actually looking at?

Look at the page before you touch any files. Several different things produce a page that looks like maintenance mode, and deleting .maintenance only fixes one of them.

What you see	Likely source	Where to turn it off
Plain text: “Briefly unavailable for scheduled maintenance. Check back in a minute.”	WordPress core’s update lock	Delete .maintenance from the WordPress root
A designed page with your logo, a countdown or an email signup	A maintenance or coming-soon plugin	That plugin’s own Status setting
A page branded by your hosting company	A maintenance switch in the host’s control panel	The host dashboard
The page appears on one device or one URL but not others	A page, server or CDN cache holding an old copy	Purge each cache layer
The site is stuck after a rollback	The rollback tool’s own lock file	For WP Rollback, .wpr-maintenance

Check while logged out, in a private browser window. Maintenance plugins usually let logged-in administrators through, so your view and your visitors’ view can be completely different.

How to clear the core lock without breaking an update

Delete only .maintenance, and only once you are sure the update has stopped. WordPress’s own update documentation describes maintenance mode as normal and short during an update. It says to remove the file only after the update has failed and is no longer running. If you delete it while files are still being replaced, visitors can reach a half-installed plugin or theme.

You need file access: your host’s file manager, SFTP or SSH. You do not need wp-admin.

1. Wait, then confirm nothing is running. Don’t close any tabs mid-update. Ask anyone else with admin access whether they started an update. If the message appeared seconds ago, give it a few minutes.
2. Take a backup if you can. Your host’s snapshot tool is fine. It gives you a known state to return to before you retry anything.
3. Open the real WordPress root. That is the folder containing wp-config.php, wp-admin and wp-includes. It is often public_html, but not always. Sites installed in a subfolder or on an addon domain live elsewhere.
4. Show hidden files. The name starts with a dot, so many file managers and SFTP clients hide it by default. Kinsta’s documentation points this out. Turn on “show hidden files” or the equivalent option.
5. Delete .maintenance and nothing else. Don’t touch wp-content/maintenance.php if you have one. That file only customises the message and is not the lock.
6. Reload the site logged out. Use a private window. If you run a caching plugin or a CDN, purge it.

Over SSH, the delete is one command run from the root:

ls -la | grep maintenance
rm .maintenance

Some developers also check wp-content/upgrade after a failed update. Leftover folders in there suggest the update stopped partway through. This is practitioner advice rather than something in WordPress’s documentation, but it is a quick way to see whether anything was left half-done.

Why ten minutes matters

The file contains a timestamp called $upgrading. WordPress’s developer reference for wp_is_maintenance_mode() says core treats the file as active only while that timestamp is less than 10 minutes old. After that, core stops showing the message, even if the file is still there.

So if you see the core message well past ten minutes, something else is involved. Usually it is one of two things: a cache serving a stored copy of the page, or an update being retried and writing a fresh .maintenance each time. Deleting the file again won’t fix either.

What to check when deleting the file changes nothing

If there is no .maintenance file, or deleting it changed nothing, work through the other sources in this order.

A maintenance or coming-soon plugin is still on

These plugins have their own switch, separate from core. In LightStart (formerly WP Maintenance Mode), Themeisle’s documentation puts it at Dashboard > LightStart > General > Status. Turn it off and save. The same documentation notes that logged-in admins may see the normal site while visitors see the maintenance page.

If the plugin is blocking the login page, rename its folder in wp-content/plugins over SFTP or the file manager. That deactivates it. In one WordPress.org thread, LightStart kept redirecting the login page because a second plugin had hidden the login URL and LightStart didn’t know to let that URL through. Renaming the LightStart folder got the owner back in. Afterwards, rename the folder back and fix the settings. Our article on when to use a maintenance mode plugin covers how these plugins decide who gets through.

Your host has its own switch

Some managed hosts add a maintenance toggle to their control panel or to a helper plugin they install. If the page carries your host’s branding, turn it off there, not in WordPress.

A cache is serving the old page

In one WordPress.org case, the homepage kept showing the maintenance page on phones and other people’s devices. That carried on after the plugin was turned off and even after its folder was removed. A cache-bypass URL showed the normal site, which pointed to the server’s cache. Purge every layer: the caching plugin, the host’s server cache (Nginx, LiteSpeed) and the CDN. Then test in a private window. The checks in fixing a page that is not updating follow the same order.

A rollback tool left its own lock

WP Rollback uses its own .wpr-maintenance file. In one support case, a FooGallery rollback from 3.3.7 to 3.3.3 actually worked, but the site stayed in maintenance mode. The plugin’s author explained that the file clears itself after 10 minutes, or you can delete it.

Why it comes back on every update

If you have to delete the file after every update, the file is not the problem. Something is making the update fail, and each failed attempt leaves a new lock behind. Practitioners report three causes most often.

A plugin that breaks the updater. In early 2023, a bug in Starter Templates caused “Update failed: -1” errors. Owners found every plugin update dropping their site back into maintenance mode. The plugin’s support team marked it resolved in version 3.1.26. That bug is long fixed, but the pattern still applies. Deactivate the suspect plugin, update it, and reactivate it. The Health Check & Troubleshooting plugin can disable plugins for your own session only, so you can test without changing what visitors see.

File ownership and permissions. If WordPress can’t write to the plugin folders, the update fails after maintenance mode has already started. Mike Sewell described a client site where the auto-updater retried one plugin update twice a day. Each time it entered maintenance mode for about 4 seconds, then failed on folder ownership. It failed 59 of 62 attempts in a month. The only sign was an uptime monitor reporting brief outages. Your host can fix ownership. Another sign of the same problem is WordPress asking for FTP credentials when you click Update.

Timeouts and memory limits. These come up most during bulk updates on modest hosting. Update one plugin at a time, and ask your host what PHP limits your plan allows.

In every case, the error log names the cause faster than guessing does. On WordPress.org, a volunteer gave exactly this advice to an owner whose plugin updates kept locking the site after a core update: check the PHP error log or debug.log.

How to confirm the site is really back

When the maintenance page goes away, you have your site back, but the update may not have finished. Before you call it done:

• Load the homepage and one inner page in a private window.
• Open Dashboard > Updates and Plugins. Check the version of whatever was updating. If it is still on the old version or shows an error, retry that single update.
• Submit a form and confirm the email arrives.
• If a fatal error appears, WordPress’s recovery mode email gives you a link to pause the broken plugin. The white screen fix guide walks through it.

On WooCommerce, WooCommerce’s update guide says to put the store in Coming soon mode during updates. It also says to run any required database update and to test store workflows, including checkout, before reopening. A store that loads but can’t take payment is worse than one that is visibly closed.

How to stop the next update from locking the site

Most stuck sites come down to how the update was run. Back up first. Test risky updates on a staging copy of the site. Update one plugin at a time, and load the site after each one rather than updating ten at once. WooCommerce’s guide likewise warns against running several major updates together unless you have tested that exact set. For stores, use Coming soon mode during the update.

If you’d rather not do this yourself, SiteSelf runs plugin updates one at a time on request. It fetches the page afterwards and reports what changed. File work, like removing a stuck lock, needs hosting (SSH) access.

When to stop and get help

Stop deleting files and contact your host or a developer in these cases:

• The same update fails twice at the same point.
• Your hosting control panel is unreachable too, which suggests an outage at the host rather than in WordPress.
• File permissions won’t let you delete the file.
• Your host reports suspicious code.

In that last case, don’t simply restore a backup, because the backup may contain the same infection. Bring the error log with you. It turns a vague report into a fix someone can act on.

Frequently asked questions

Is it safe to delete the .maintenance file?

Yes, once the update has stopped. The file only tells WordPress to show the maintenance message. Removing it changes no plugin, theme or database content. The risk is timing: deleting it during an active update can expose half-replaced files.

How long should maintenance mode normally last?

For a normal update, seconds. WordPress’s documentation calls it a short time, and in the ownership case above it lasted about 4 seconds per attempt. Core stops honouring the file after 10 minutes, so anything much longer means something else is involved.

I can’t find the .maintenance file. Where is it?

It is in the folder that holds wp-config.php, not inside wp-content. It is hidden because the name starts with a dot, so turn on hidden files in your file manager or SFTP client. If it really isn’t there, the page is coming from a plugin, your host or a cache.

Why does the site look fine to me but not to visitors?

Maintenance plugins usually let logged-in users through, and caches can store different copies for different devices. Always check logged out in a private window, and on a phone if the report came from one.

Does maintenance mode hurt SEO?

A few minutes won’t. A long outage can, because search engines slow down crawling when they keep getting server errors. Our article on the 503 response code explains which status a planned outage should return.

Should I turn off automatic updates to stop this?

Some owners do, and run updates by hand during quiet hours. That gives up automatic security fixes, though. If auto-updates keep failing, fix the cause first, usually ownership or a broken plugin, and decide on auto-updates after that.