Briefly Unavailable For Scheduled Maintenance: How To Fix It

You updated a plugin, the page went white for a second, and now every visitor sees a single line of text: Briefly unavailable for scheduled maintenance. Check back in a minute. Your admin is gone too, so there is nothing obvious to click.

Nearly every guide to this error tells you to delete a file called .maintenance from your site root. That does usually clear it. But it is worth knowing before you reach for an FTP client that WordPress is supposed to clear that file on its own after ten minutes, so if the message has been up for an hour, the file is often not what is holding you there.

This walks through what the message actually is, the quick fix, and the two things to check afterwards that almost nobody mentions: whether the update that triggered it ever finished, and whether the outage lasted long enough to matter to Google.

What the message actually means

It is not an error. It is WordPress doing what it was designed to do.

When WordPress updates core, a plugin or a theme, it creates a file named .maintenance in your installation root, alongside wp-config.php. The file contains a single timestamp. While it exists, WordPress stops serving the normal site and shows that holding message instead.

The reason is sound. During an update, files are being swapped out underneath a running application. If visitors kept hitting the site mid-swap, they could load half of an old plugin and half of a new one, which produces errors far stranger and harder to diagnose than a holding page. So WordPress closes the doors, does the work, and deletes the file when it finishes.

You are seeing the message because the update did not reach the step where the file gets deleted. Something interrupted it.

The ten minute rule nobody mentions

Here is the part that changes how you should approach this. WordPress does not trust that file indefinitely. It checks how old the timestamp inside it is, and if it is more than ten minutes old, it ignores the file entirely and serves the site as normal.

The check lives in wp_is_maintenance_mode() and reads, in effect: if the time since the upgrade started is ten minutes or more, maintenance mode is over. The stale file can sit in your root forever and WordPress will step over it.

Two useful consequences follow:

• If the message appeared in the last few minutes, wait. There is a reasonable chance it clears itself and you need do nothing.
• If it has been showing for much longer than ten minutes, the file is probably not the cause. Deleting it is harmless and worth doing, but if the message survives that, stop looking at the file and read the next section.

This is why so many people report deleting .maintenance and seeing no change. They were never stuck on the file.

So why is it still showing

Four causes, in the order they are worth checking.

1. You are looking at a cached copy

By far the most common. Your caching plugin, your CDN or your own browser saved the holding page while it was live and is still handing it out. The site underneath is fine.

Test it in a private window, or add a meaningless query string such as ?x=1 to the URL, which bypasses most caches. If the site loads, you have a cache to purge rather than a broken site.

2. A maintenance mode plugin is switched on

Plenty of sites run a plugin that shows a deliberate holding page. If somebody enabled one and forgot, or a plugin turned itself on during an update, the wording can look similar enough to confuse. The giveaway is a designed page rather than a bare line of text on a white background.

3. The update genuinely failed partway

If the file really is recent and keeps being recreated, an update is still trying and failing. This is the one that needs care, and it is covered below.

4. Your server clock is wrong

Rare, but it happens. The ten minute rule compares the timestamp in the file with the current server time. If the clock is skewed so the file appears to have been created in the future, that comparison never passes and the message never expires. If everything else here has failed, ask your host to check the server time.

Fixing it, in order of risk

Work down this list. Stop when the site comes back.

Deleting the file

The file is called .maintenance. The leading dot matters, and it means the file is hidden by default in many tools, so if you cannot see it, that is usually why rather than it being absent.

Through your hosting file manager

Open the file manager in your hosting control panel and go to the folder holding wp-config.php, commonly public_html. Enable showing hidden files, which is normally a setting or a toggle rather than obvious. Delete .maintenance, then reload your site.

Through FTP

Connect with any FTP client, open your site root, and switch on hidden files. In FileZilla that setting is under Server, then Force showing hidden files. Delete the file and reload.

Through SSH, if you have it

One command from the site root:

Deleting this file cannot damage your site. It holds a timestamp and nothing else, and WordPress recreates it the next time it runs an update.

Now check the update actually finished

This is the step most guides skip, and it is the one that matters. Removing the file removes the sign that an update was in progress. It does not finish the update.

If the process died partway, you may now have a plugin whose files are half old and half new. Sometimes that is obvious, because something is visibly broken. Sometimes the site looks completely normal while a plugin sits in a state its author never tested, which is worse, because you will not connect the symptoms to this event a fortnight from now.

Once the site is back, do this:

• Open Dashboard, then Updates. Whatever was updating will usually still be listed as needing an update. That tells you it did not complete.
• Update it again, on its own. Not in a batch with fifteen others. If it completes cleanly this time, you are done.
• If it fails again, reinstall rather than update. Deactivate the plugin, delete it, and install it fresh. Settings live in the database and survive this in almost all cases, but take a backup first.
• If WordPress core was updating, reinstall core. Updates, then Re-install Now. This replaces core files without touching your content.
• Load a few real pages and, if you sell, place a test order. A half-applied update to anything near checkout is exactly the failure that goes unnoticed for a week.

An interrupted plugin update is also a security consideration, not only a stability one. If the update was a security release, you are still running the vulnerable version while your dashboard may show otherwise. Our guide to WooCommerce security covers why patch speed matters more than any security plugin, and the same logic applies to any WordPress site.

If the message keeps coming back

A .maintenance file that reappears after you delete it means something is still trying to update and still failing. Deleting it repeatedly is treating the symptom.

Usual causes, and what to do:

• The update is timing out. A large plugin on a slow or throttled server can exceed the PHP execution limit every time. Ask your host whether max_execution_time or the memory limit is being hit.
• File permissions changed. If WordPress cannot write to wp-content, updates fail at the same point every time.
• Disk is full. Unglamorous and more common than you would expect, particularly where backups are written to the same server.
• Auto-updates are retrying. If automatic updates are on and one is failing, it will keep attempting on a schedule, recreating the file each time.

If you cannot get past it, restoring a backup taken before the update is a faster and safer route than escalating through core file edits. Some advice on this topic suggests editing wp-activate.php to change a constant. That file governs multisite signup and has nothing to do with the .maintenance file, so it is not a fix worth trying.

Does this hurt your SEO

Briefly, no. For a long outage, yes.

While maintenance mode is active WordPress returns a 503 status, which means temporarily unavailable, along with a Retry-After header. That is exactly the right signal, and it is the behaviour Google's own guidance recommends for a site that is briefly down. A crawler that receives it understands to come back later rather than concluding your pages have gone.

The risk is duration. A few minutes is invisible. A site left in this state for days is repeatedly telling Google it is unavailable, and prolonged 503s eventually cost you crawling and then rankings. The practical rule: if you cannot fix it quickly, restoring a backup is better for your search visibility than leaving the holding page up while you work out the cause.

It is worth checking Search Console afterwards for crawl errors dated to the outage, particularly if it ran overnight before anyone noticed.

Why it happened in the first place

The update stopped between creating the file and deleting it. Something in that window went wrong:

• The browser tab was closed, or the connection dropped. On older WordPress versions the update ran in the request, so closing the tab stopped it mid-way.
• The server timed out. The most common cause on shared hosting, and the one that repeats. Updating twenty plugins at once means twenty downloads, twenty unzips and twenty file operations in one request.
• The site ran out of memory. Same shape of problem, different limit.
• A conflict crashed the process. Less common, but a fatal error triggered by the newly written files can stop everything before cleanup.

The pattern behind most of these is resources. If this happens to you regularly rather than once, the updates are not the problem. Our piece on the signs a web host is failing you covers when that becomes the answer, and managed versus shared hosting covers what actually changes when you move.

Stopping it happening again

Five habits, in the order they pay off.

• Update on staging first. A copy of the site where a failed update strands nobody. This is the single change that turns this from an emergency into a non-event, and it is standard on managed hosting. Ours is on the control panel.
• Update in small batches. Three or four at a time, not twenty. Each batch is a shorter request, far less likely to time out, and if something breaks you know which one did it.
• Take a backup you can restore yourself. Not one that needs a support ticket. The value of a backup is entirely in how fast you can use it.
• Do not close the tab. Cheap advice, but it still applies if you are updating manually.
• Keep to a schedule. Security releases promptly, everything else on a monthly pass. Our WordPress maintenance checklist sets out a cadence, and for stores WooCommerce maintenance covers the extra checks a shop needs.

None of this is exotic. The reason this error is so common is that most sites update straight into production with no way back, so the first thing that goes wrong is visible to customers. Change that one habit and the message stops being something you have to search for at nine on a Friday evening.