Briefly unavailable for scheduled maintenance: how to fix a stuck WordPress update

Your visitors see a plain page with a single line: "Briefly unavailable for scheduled maintenance. Check back in a minute." Normally that message flashes past in a few seconds during an update. If it has been visible for more than ten minutes, your site is stuck and needs a manual nudge.

What this message actually means

WordPress is in maintenance mode because a file called .maintenance exists in the site root (the directory that holds wp-config.php). When the update runs, WordPress sends an HTTP 503 response with the message above and a Retry-After: 600 header, asking clients to come back in ten minutes. As long as the file is there and the timestamp inside it is recent, every visitor sees the maintenance screen instead of your site.

The process is straightforward. When an update starts, WP_Upgrader::maintenance_mode() writes a tiny PHP file that looks like this:

<?php $upgrading = 1735838412; ?>

That number is the Unix timestamp of the moment the update began. When the update finishes normally, WordPress deletes the file. Maintenance mode ends. Your site is back.

Why WordPress should recover on its own, and when it does not

There is a safety valve built into WordPress. The wp_is_maintenance_mode() function reads the $upgrading timestamp and treats the file as stale once it is more than ten minutes old: ( time() - $upgrading ) >= 10 * MINUTE_IN_SECONDS. If you wait ten full minutes and the maintenance message is gone, WordPress handled it for you, and you can skip straight to prevention.

The safety valve has one blind spot. If the .maintenance file was written but the update crashed hard enough that WordPress cannot reach the cleanup step, the file stays on disk. Visitors still see the 503. But the timestamp inside is now older than ten minutes, and the message shifts: WordPress stops showing the maintenance screen and instead shows "Briefly unavailable for scheduled maintenance. Check back in a minute." as a bare 503 only while the timestamp is still fresh. In practice, most people notice the error while it is still fresh, and the 10-minute rule never kicks in before they start troubleshooting.

If you are reading this, the file is almost certainly still there and needs to be removed by hand.

Common causes, ordered by likelihood

1. The update triggered a fatal PHP error. A plugin or theme you just updated threw a fatal during activation or setup, and WP_Upgrader never reached the "disable maintenance mode" step. This is by far the most common cause. The site often shows the maintenance screen briefly and then reveals a different error once you clear the file. See my guide to the "There has been a critical error on this website" message if that happens.
2. You refreshed, closed the browser tab, or navigated away mid-update. Closing the tab in the WordPress dashboard does not stop the update by itself (the server keeps running), but impatient clicks and manual wp-admin refreshes can cause WordPress to miss the cleanup callback.
3. A syntax error in an updated plugin or theme file. If the new version of a plugin or theme has a PHP parse error, the PHP process can die halfway through the update and the .maintenance file is left stranded.
4. A PHP timeout or out-of-memory kill during the update. Shared hosts with tight max_execution_time or low memory_limit can terminate the update process mid-run, especially when you update a large plugin or push core, multiple plugins, and themes at the same time.
5. A filesystem permissions problem. If WordPress could write .maintenance but cannot delete it at the end (because directory ownership changed, or because an SFTP user has different permissions than the webserver user), the file stays put even though the update itself finished cleanly.

Once you have a hypothesis about which cause applies, the fix is the same. Remove the file, see what the site looks like underneath, and address whatever is waiting there.

Diagnose before you delete

Before you remove the file, confirm you are looking at the real symptom.

• Check the browser's developer tools. Open the Network tab and reload the page. The main document should return HTTP 503 with the message "Briefly unavailable for scheduled maintenance. Check back in a minute." If you see a 500, a different error page, or a blank white screen, you are probably dealing with a different problem, such as a critical error or a generic 503 caused by server overload.
• Wait one minute and reload. Real updates usually finish in seconds. If the message is still there after 60 seconds, the file is stranded. Do not wait hours hoping it clears; the 10-minute auto-recovery is the longest it would ever take on its own.
• Look at your hosting provider's status page. If your host is running maintenance themselves, the 503 can come from them, not from WordPress. In that case there is no .maintenance file in your site root to remove.

If the 503 really comes from the .maintenance file, move on to the fix.

The fix: remove the .maintenance file

You need file access to the WordPress root directory. That is the folder containing wp-config.php, wp-settings.php, and the wp-content directory. On most hosts this is public_html or a subfolder of it. Pick whichever of these three methods matches the access you have.

Method A: SFTP

1. Connect to the server with your SFTP client (FileZilla, Cyberduck, Transmit, or similar) using your host's SFTP credentials.
2. Navigate to the WordPress root. You will see wp-config.php in the listing. If you do not, you are in the wrong folder.
3. Enable show hidden files in your client. In FileZilla this is under Server → Force showing hidden files. The .maintenance file starts with a dot, so it is hidden by default.
4. Right-click .maintenance and choose Delete.
5. Reload your website in the browser.

You will know it worked when: the homepage loads normally (or shows a different error, which means you found a deeper problem that was masked by the maintenance screen). The 503 status is gone from the Network tab.

Method B: Hosting control panel file manager (cPanel, DirectAdmin, Plesk)

1. Log in to your hosting control panel and open the File Manager.
2. Navigate to the WordPress root (usually public_html or the site-specific folder on DirectAdmin and Plesk).
3. Turn on hidden files. In cPanel File Manager click Settings in the top-right and tick Show Hidden Files (dotfiles). DirectAdmin and Plesk have similar toggles.
4. Select .maintenance and click Delete. Confirm the deletion.
5. Reload your website in the browser.

You will know it worked when: the site loads a normal page and the 503 is gone. If you see a critical error instead, the underlying update problem is now visible and you can troubleshoot it directly.

Method C: SSH with WP-CLI

If you have SSH access and WP-CLI installed, this is the fastest option.

1. SSH into your server.
2. Change directory to the WordPress root: cd /var/www/yoursite.com/public (adjust the path to your install).
3. Run wp maintenance-mode deactivate. This removes the .maintenance file.
4. Reload your website in the browser.

The expected output is:

Success: Disabled Maintenance mode.

If WP-CLI reports Warning: Maintenance mode already disabled., the file was already gone. That usually means the 10-minute timer just expired, or the 503 you saw came from somewhere else.

You will know it worked when: wp maintenance-mode status returns Maintenance mode is disabled. and your browser loads the site.

What to do if removing the file does not fix the site

Most of the time the site comes right back. When it does not, the .maintenance file was only the outer layer. Something deeper crashed during the update, and you will now see that crash instead of the maintenance screen.

• If the site now shows "There has been a critical error on this website", work through my step-by-step guide for that message. A freshly updated plugin or theme is almost always the culprit.
• If you see a parse error or a white screen with a PHP error message, follow my syntax error, unexpected troubleshooting article. The new version of a plugin or theme was shipped with broken PHP for your version.
• If the site keeps going back into maintenance mode every few minutes, a scheduled auto-update is retrying and failing. Rename the misbehaving plugin's folder in wp-content/plugins/ to disable it, then reload the site. The full diagnostic walk-through for repeated failed automatic updates lives in an automated WordPress update has failed to complete: how to safely recover.
• If .maintenance reappears on its own within seconds, something on your server is recreating the file. This is rare, but it happens on misconfigured multisite or when a security plugin's "under attack" mode writes a similar file. Disable the security plugin by renaming its folder and try again.

When to escalate

If you have removed the .maintenance file, reloaded, waited, and the site still does not work, it is time to ask for help. Collect the following before you open a ticket:

• The exact URL and the exact error text you see now (not just the original maintenance message).
• Your WordPress version, PHP version, and active theme.
• The plugin or plugins that were being updated when the problem started, and their versions before and after the update.
• The timestamp inside the .maintenance file before you deleted it (open the file first, it contains a line like <?php $upgrading = 1735838412; ?> which tells you exactly when the update began). This is the single most useful piece of context for a hosting support engineer.
• Anything in wp-content/debug.log from the past hour (if WP_DEBUG_LOG was on).
• The error log from your hosting control panel for the same time window (cPanel, DirectAdmin, and Plesk all expose one).
• A list of steps you already tried from this article.

Send all of that to your host, your developer, or your managed WordPress provider. A good support engineer can pinpoint the cause in minutes with that information.

How to avoid getting stuck next time

• Do not refresh or close the WordPress admin tab while an update is running. The update runs on the server, not in the browser, but clicking around the dashboard mid-update can cause WordPress to miss the cleanup callback. Wait for the "Updates have been completed" screen.
• Update in smaller batches. Updating core, twenty plugins, and three themes in a single click is the scenario where PHP timeouts and memory limits bite hardest. Update core alone, then plugins in groups of five, then themes.
• Test plugin and theme updates on a staging site first. Most decent hosts give you a one-click staging environment. Updating a dozen plugins on staging reveals fatal errors before your visitors see them.
• Keep backups that run immediately before updates. Both UpdraftPlus and the built-in backup in good managed hosting can trigger a backup right before an automatic update runs, so you can restore in one click if something breaks.
• Raise max_execution_time and memory_limit if you update large plugins. Sites running PageBuilders, WooCommerce, or learning management plugins often need at least max_execution_time = 300 and memory_limit = 512M to update cleanly. If your host will not let you raise these, that is a signal to look at a better plan.
• Disable automatic updates for plugins that have a history of breaking your site. A stable plugin that crashes on update twice is not worth the risk of a 3 AM outage. Disable auto-updates for it in Plugins → Installed Plugins and update it manually during the week.

The maintenance message is harmless on its own. It becomes a problem only when an update dies before it can clean up after itself, and the fix is almost always the same: remove one file, then deal with whatever broke underneath.