WordPress stuck in maintenance mode? The file to delete, and why the 10 minute rule matters

Why is WordPress stuck in maintenance mode?

WordPress gets stuck in maintenance mode when an update leaves a file called .maintenance behind. While that file is there, every visitor sees one line: “Briefly unavailable for scheduled maintenance. Check back in a minute.”

WordPress writes the file at the start of an update and deletes it at the end. If the update stops halfway, the delete never happens.

We tested what that file does on 13 Oct 2026, on a fresh WordPress 7.1.3 site with PHP 8.3.33. The surprise: WordPress stops honoring the file after 10 minutes.

A stuck update is a common way for a site to go down with nobody touching it, which is why update handling sits at the centre of our WordPress care plan.

What is inside the .maintenance file?

One line of PHP with a number in it:

<?php $upgrading = 1791899582; ?>

That number is a Unix time stamp, the moment the update started. The file sits in the WordPress root folder, next to wp-config.php.

What does the maintenance page block?

Everything we tried. With the file in place, we requested four addresses: the home page, /wp-admin/, /wp-login.php and /wp-json/, the REST API.

All four returned status 503 and the same 2,500 byte page, titled Maintenance. The response also carried a Retry-After header of 600, which tells browsers and search crawlers to come back in 10 minutes.

So the owner is locked out with everyone else, because the login page is the maintenance page too. The fix has to happen in the files.

Why should the message clear by itself after 10 minutes?

Because WordPress checks the age of the time stamp, not just whether the file exists.

We backdated the file and requested the same four addresses each time:

At 610 seconds the file was still on disk, and the site loaded as if it were gone. The function wp_is_maintenance_mode() in wp-includes/load.php returns false once the time stamp is 10 minutes old.

So a file left behind by an update that died should stop blocking the site after 10 minutes on its own.

What if it lasts longer than 10 minutes?

Then the old file alone is not the cause. Either something keeps writing a fresh time into it, or the site is down for another reason that happens to look similar.

We did not test those cases, so these are checks, not findings:

1. Open .maintenance and read the number. Convert it with any Unix time converter. If it is from the last few minutes, an update is still running or has started again.
2. Ask who else can run updates. A host’s dashboard, a management tool or plugin auto-updates can all start one. Our post on finding out who turned on WordPress plugin auto-updates shows where that setting lives.
3. Remember that background jobs wait for traffic. Auto-updates start from WP-Cron, and WP-Cron only runs when someone loads a page, so a job can start the moment your first visitor arrives.
4. If the time stamp is old and the site is still down, look past the file. Check the host’s error log, and whether the 503 page actually says “Briefly unavailable for scheduled maintenance”. A page cache or CDN may also still be serving the saved maintenance page, so purge it (we did not test this).

How do you fix it safely?

1. Wait until no update could still be running. If the time stamp is a few minutes old, give it a few more.
2. Open your host’s file manager or connect by SFTP, and go to the folder that holds wp-config.php.
3. Turn on hidden files. The name starts with a dot, so many tools hide it.
4. Delete .maintenance. Load the home page to confirm it is back.
5. Log in and open Dashboard, then Updates. Run the update that was interrupted again.
6. Open Plugins and Themes and check that what was being updated is still listed and active.

Deleting the file ends the maintenance page. It doesn’t finish the update. We did not cut off a real update in our lab, so we can’t tell you exactly what state a half-done one leaves behind, which is why step 6 matters.

This is the failure our care plan is built to keep off a live site: we run updates on a staging copy first, and only send them to the live site once the copy works.

Is your site showing the maintenance message right now?

If the file is gone and the message is still there, or the update fails again when you rerun it, tell us what the site shows and we will look at the files with you.