Briefly Unavailable for Scheduled Maintenance: Why It Is Stuck

Everyone tells you to delete the .maintenance file. WordPress already ignores it after ten minutes, which means for most stuck sites the file is not what you are looking at.

Picture of Adam Walters
Adam Walters

Founder

.maintenance. One file in your web root, and a ten minute rule almost nobody knows about.
IN THIS ARTICLE

You updated a plugin, or WordPress updated one for you overnight, and now every page on the site says one sentence and nothing else:

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

The admin is gone too. Every guide you find says the same thing: delete a file called .maintenance from your web root. That advice is correct, and for a site that has been stuck for more than about ten minutes it is also frequently beside the point, for a reason almost nobody writing about this mentions.

What the message actually is

It is not a setting, and no plugin is involved. When WordPress updates core, a plugin or a theme, WP_Upgrader::maintenance_mode() writes a single file into your WordPress root containing one line:

<?php $upgrading = 1760353200; ?>

That number is a Unix timestamp: the moment the update started. While the file exists, wp_maintenance() intercepts every request, prints that one sentence, returns HTTP 503 and sends a Retry-After: 600 header. When the update finishes, the upgrader deletes the file. That is the entire mechanism.

You get stuck when the update dies between those two steps. The file is written, something fails, and nothing ever removes it.

Diagram showing WordPress stops honouring a .maintenance file once 600 seconds have passed since its upgrading timestamp

WordPress already ignores the file after ten minutes

This is the part that changes the diagnosis. wp_is_maintenance_mode() does not simply check whether the file is there. It reads the timestamp and gives up on it:

if ( ( time() - $upgrading ) >= 10 * MINUTE_IN_SECONDS ) {
    return false;
}

Ten minutes. 600 seconds. After that, core stops honouring the file entirely and serves the site normally, whether or not anyone deleted anything.

So a site that has been showing this message for an hour is not being held there by the .maintenance file. Core would have released it fifty minutes ago. Something else is producing what you are looking at, and deleting the file will not touch it.

How long it has been stuckWhat that tells youWhat to do
Under 10 minutesWorking exactly as designed. An update is in progressWait. Interrupting it is how sites get half-updated
Cleared on its own after 10 minutesThe update died, but core timed the file out for youDelete the leftover file, then verify the update actually completed
Still stuck after an hourCore is not producing this responseLook at your page cache or CDN, not the file
Gone when logged in, present logged outA cached 503 being served to anonymous visitorsPurge the cache
Wording is not exactly the sentence aboveNot core maintenance mode at allA plugin’s own maintenance mode. Look in the plugin list
The elapsed time is the diagnostic. Four of these five have nothing to do with deleting a file.

The straightforward case

If it has been under ten minutes, wait. Genuinely. An update that is still copying files will finish, and cutting it off part way is how you end up with a half-written plugin directory, which is a considerably worse problem than a holding page.

Past that, connect over SFTP, SSH or your host’s file manager, go to the folder containing wp-config.php, and delete .maintenance. Two things catch people here. The leading dot makes it a hidden file, so most file managers and FTP clients will not show it until you turn on “show hidden files”. And it sits in the WordPress root, not in wp-content.

Then check what the interrupted update left behind. Go to Dashboard → Updates and confirm the plugin or theme is actually at the version it should be. A failed update can leave the old files, the new files, or an unhappy mixture of both.

Comparison showing that a site still stuck after an hour is usually serving a cached 503 rather than still reading the .maintenance file

When deleting the file changes nothing

A cache is serving the 503. This is the common one. A full-page cache, a CDN or a reverse proxy stored the maintenance response and is handing it back without ever running WordPress. Core times out its own file, the site is fine, and every visitor still sees the holding page. Purge the cache at every layer you have, including the CDN, and test in a private window.

Something keeps rewriting the file. An auto-update that fails and retries recreates .maintenance with a fresh timestamp every time, which resets the ten minute clock indefinitely. If the file reappears within minutes of deleting it, that is what is happening. Disable auto-updates temporarily and update by hand so you can see the failure.

It is a plugin’s maintenance mode, not core’s. Several plugins ship a coming-soon or maintenance screen. None of them produce this exact sentence. If the wording differs by even a word, you are looking at a plugin setting, and no amount of deleting files in the root will help.

Why the update died in the first place

Clearing the holding page gets the site back. It does not tell you why the update stopped, and the same thing will happen at the next one.

Three causes account for most of them. PHP ran out of memory part way through unpacking the update, which leaves the exact fingerprint described in the allowed memory size error. The request exceeded the maximum execution time on a slow or oversubscribed host. Or the update was a scheduled automatic one running under WP-Cron, which inherits whatever limits that request was given and fails quietly with nobody watching.

That last one is worth sitting with. Automatic updates are the single most common way a site ends up stuck like this, precisely because they run at 3am with no human present to notice the failure. The holding page is often the first anyone hears about it, hours later.

Making it not happen again

There is a filter, enable_maintenance_mode, that can switch the behaviour off entirely. Do not reach for it. Maintenance mode exists so visitors do not hit a site with half its files replaced, and turning it off swaps a holding page for genuinely broken output.

What actually helps is unglamorous: enough PHP memory and execution time for updates to complete, updates applied where someone is watching rather than at 3am, and a backup taken immediately before, so a failed update is a restore rather than an investigation. Our website maintenance checklist covers the sequence, and the same reasoning runs through what a maintenance plan should actually cover.

If you would rather updates were somebody else’s problem, and somebody else’s 3am, that is the whole proposition of managed WordPress hosting.

Frequently asked questions

Where is the .maintenance file?

In the WordPress root, the same folder as wp-config.php and wp-load.php. Not in wp-content. The leading dot makes it a hidden file, so most FTP clients and host file managers will not display it until you enable “show hidden files”, which is why people often conclude it is not there.

Is it safe to delete the .maintenance file?

Yes, provided an update is not still running. The file holds nothing but a timestamp, and the upgrader deletes it itself on a successful update. The risk is not the deletion, it is deleting it while files are still being copied, which leaves a half-updated plugin or theme. If it has been under ten minutes, wait first.

Why is my site still showing the message an hour later?

Because core is almost certainly not producing it any more. WordPress stops honouring a .maintenance file once 600 seconds have passed since its timestamp, so after ten minutes the file is inert. A response you are still seeing after an hour is usually a cached 503 held by a page cache, a CDN or a reverse proxy. Purge those before touching anything else.

The file keeps coming back after I delete it. What does that mean?

An update is failing and retrying, recreating the file with a fresh timestamp each time and resetting the ten minute clock. Turn automatic updates off temporarily and run the update manually so you can see the actual error rather than only its side effect.

Can I stop WordPress using maintenance mode at all?

There is a filter called enable_maintenance_mode that will do it, and it is a bad trade. Maintenance mode exists so visitors do not load a site whose files are half replaced. Removing it does not prevent failed updates, it just makes them look like broken pages instead of a holding message.

My message is worded slightly differently. Is that the same thing?

No. Core emits exactly “Briefly unavailable for scheduled maintenance. Check back in a minute.” and nothing else. Any other wording, any added branding, any countdown timer, is a plugin providing its own maintenance or coming-soon screen. Look for that setting in your plugin list rather than for a file.

Is your competitor stealing traffic?

Get a free competitor spy report. See their keywords, backlinks, and map rankings.

SHARE:
The allowed memory size error contains two numbers, and the second one tells you which…
October 6, 2026
Wordfence empties wp_wfHoover after every scan by design. If yours is gigabytes, a scan stopped…
September 29, 2026
wp_postmeta is meant to be your biggest table. The size is rarely the problem —…
September 22, 2026
Get the Blueprint

Join 5,000+ local business owners receiving weekly growth tactics.

Get Your Free Audit

See where you stand before you launch.