Fix WordPress stuck in maintenance mode

Checked 10 November 2026 · WordPress 7.1.4 · PHP 8.3.6 · MariaDB 10.11.14 · WP-CLI · Read time: 5 minutes

Case file

Symptom: “Briefly unavailable for scheduled maintenance”, HTTP 503
Cause: An interrupted update left a .maintenance file in the site root
Fix: Delete the .maintenance file
Result: The homepage returns HTTP 200 again

The break · What you need · The diagnosis · The fix · Verify · If that didn’t work · What happened · Where this came from

The break

Every time WordPress runs an update it writes a small file called .maintenance into the site root, and while that file exists every visitor sees one sentence instead of the site. When the update finishes, WordPress deletes the file. If the update is interrupted — the server times out, PHP crashes, the connection drops — the file stays behind and the site stays “down” even though nothing is still updating. The official list of common errors says exactly this: the maintenance file may not have been removed properly, and the fix is to delete it.

This guide reproduces the break first. A disposable install had a .maintenance file written into its root with the current time in it, the way an interrupted update leaves one. The homepage went from HTTP 200 to HTTP 503, and deleting the file brought it straight back.

What you need

Access to the server files (SSH, SFTP, or your host file manager). The dashboard cannot fix this: while the file is fresh, wp-admin shows the same message.
WP-CLI installed, if you want the command-line version of the fix.

The diagnosis

1. Confirm the symptom

Load the homepage and note the status code, not just what the browser shows. In the reproduction, the homepage returned HTTP 503 with the standard WordPress maintenance message:

Output — homepage with a fresh .maintenance file

HTTP 503
<title>Maintenance</title>
Briefly unavailable for scheduled maintenance. Check back in a minute.

Key result: HTTP 503 plus that exact sentence is WordPress’s own maintenance page. A differently worded page, or one with your logo on it, comes from a maintenance plugin or from the host instead — and deleting .maintenance will not clear it.

2. Check the .maintenance file exists

Look in the site root — the folder that holds wp-config.php — for a file called .maintenance. The leading dot makes it a hidden file, so turn on “show hidden files” in your file manager, or list it over SSH:

Command — check for the lock file

ls -la .maintenance

Before deleting anything, make sure no update is actually running. If someone started an update a minute ago, the file is doing its job and the site will come back on its own when the update finishes. The file to delete is a leftover from an update that already stopped.

Trap: do not delete the wrong .maintenance file. A hosting account can hold more than one site, and the right folder is the one that holds that site’s wp-config.php. If ls -la .maintenance says “No such file or directory”, the lock file is not the cause — skip to the fallback section.

The fix

3. Delete the .maintenance file

Delete the file from the site root. Over SSH:

Command — remove the lock file

rm .maintenance

Or delete it in your host’s file manager, with hidden files shown. With WP-CLI, the same file is removed by the maintenance-mode command, which the reproduction verified independently: a fresh .maintenance file, then wp maintenance-mode deactivate, and the file was gone.

Command — remove the lock file with WP-CLI

wp maintenance-mode status
wp maintenance-mode deactivate

Output

Maintenance mode is active.
Disabling Maintenance mode...
Success: Deactivated Maintenance mode.

Verify the site is back

Load the homepage again and check the status code:

Output — homepage after deleting .maintenance

HTTP 200
<title>SRM Test</title>

Step	Homepage status
Healthy site	HTTP 200
Fresh `.maintenance` file present	HTTP 503 — maintenance message
After deleting `.maintenance`	HTTP 200
After `wp maintenance-mode deactivate`	HTTP 200

If that didn’t work

Wait ten minutes — or check whether the message is even WordPress’s

The .maintenance file holds one line of PHP: the time the update started. WordPress compares that time with the clock on every request, and once ten minutes have passed it stops treating the site as being in maintenance. The reproduction verified this: a .maintenance file stamped eleven minutes in the past left the homepage loading normally at HTTP 200, with the file still sitting there.

So if the message is still on screen after ten minutes, WordPress’s own maintenance mode is not what is showing it. Check for a maintenance or coming-soon plugin that is still switched on, a wp-content/maintenance.php drop-in file that replaces WordPress’s plain message with a custom page, or a holding page served by the host.

Check the update did not half-finish

Deleting the file makes the site visible again, but it does not finish the update that was interrupted. Once the site loads, check the plugin, theme, or core item that was updating: confirm its version in the dashboard, and if the update only half applied, run it again from a backup. If the file keeps coming back, something is still starting updates — find that process instead of deleting the file a second time.

What happened

An interrupted update left a .maintenance file in the site root, and every visitor saw “Briefly unavailable for scheduled maintenance” with HTTP 503. The file was deleted from the root — and independently removed a second time with wp maintenance-mode deactivate — and the homepage returned HTTP 200 both times.

Where this came from

WordPress writing a .maintenance file during updates, the file not being removed properly, and the fix — log in by FTP and delete the .maintenance file from the site root — come from Common WordPress errors — WordPress.org.
The wp maintenance-mode command, which deletes the same file, comes from wp maintenance-mode — Developer.WordPress.org.