You update a plugin, refresh the page, and the whole site is replaced with a message: “Briefly unavailable for scheduled maintenance. Check back in a minute.” A minute passes. Then ten. Then an hour, and the site is still down. I’ve had more than one client email me this exact scenario in a panic. Nothing is broken in the way it looks — this is a very fixable problem, and it takes about two minutes once you know where to look.

What the maintenance screen actually is

WordPress doesn’t have a fancy maintenance system behind that message. When you trigger an update — core, a plugin, a theme, even a bulk update from the Plugins screen — WordPress writes a tiny file called .maintenance into your site’s root folder. That’s the same folder that holds wp-config.php, the file that stores your site’s core settings like the database connection.

The .maintenance file itself is nothing complicated. It’s one line of code with a timestamp in it:

<?php $upgrading = 1234567890; ?>

That number just records when the update started, down to the second. Here’s the important part: while that file exists, WordPress intercepts every visitor before your theme even loads, and shows them the maintenance message instead. That’s by design. You don’t want people clicking around on a site that’s half-updated.

When the update finishes normally, WordPress deletes .maintenance on its own and your site goes back to normal. The problem is what happens when the update doesn’t finish.

Why it gets stuck

The file gets left behind when the update process dies before it reaches the cleanup step. In my experience, a handful of causes account for almost every case:

• The PHP process ran out of time or memory partway through. This is common on shared hosting when a big theme or several plugins are updating at once.
• The browser tab got closed, or the connection dropped, while the update request was still running.
• A fatal error in the plugin or theme code itself killed the request before WordPress could remove the file.
• An auto-update job kept retrying and failing.

That last one deserves its own explanation, because it’s the case that makes the problem look permanent. WordPress actually has logic to ignore a stale .maintenance file after about 10 minutes and let the site load normally again. But a background retry loop can rewrite the file with a fresh timestamp every time it tries again, which resets that 10-minute clock indefinitely. If your site auto-updates and something about the update keeps failing, you can end up stuck for a long time. That kind of unattended retry is closely tied to how WordPress schedules background tasks in the first place — a system that’s a lot less reliable than people assume, which I cover in why WP-Cron isn’t a real cron job.

How to remove it safely

The fix is simply deleting the file. It won’t break anything, because it isn’t part of your site’s actual code or database — it’s just a traffic light WordPress checks before doing anything else.

Via FTP/SFTP

FTP (or its more secure version, SFTP) is just a way to browse and edit your site’s files directly, the same way you’d browse folders on your own computer. Connect with FileZilla or whichever client you use, and navigate to the folder that contains wp-config.php and the wp-content folder. Make sure “show hidden files” is turned on in your client’s settings — filenames starting with a dot are hidden by default. Find .maintenance and delete it.

Via your host’s File Manager

Most hosting control panels (cPanel, Plesk, and similar) include a File Manager you can use straight from your browser, no separate software needed. Same idea as FTP: go to your site’s root folder, turn on “show hidden files,” find .maintenance, and delete it.

Via SSH

SSH gives you a command-line window straight into your server. It’s my preferred way when I have access, because it’s instant:

cd /path/to/your/site
ls -la
rm .maintenance

Running ls -la first is worth the extra step — it confirms you’re in the right folder and that the file is actually there before you delete anything.

After you delete it

Don’t just walk away once the site is back up. Check what actually failed first:

• Go to Dashboard → Updates and confirm plugins, themes, and core are actually on the version you expected. Sometimes an update partially applies and needs to be run again.
• Check wp-content/debug.log, if WP_DEBUG_LOG is turned on, or your host’s PHP error log, for a fatal error or timeout around the time it happened.
• If one specific plugin caused it, update that plugin by itself next time instead of bulk-updating everything at once.

Avoiding it next time

A few habits have cut this down to almost zero on the sites I maintain:

• Update plugins one or two at a time instead of selecting everything and clicking “Update” in one batch. A single slow plugin can eat the whole request’s time budget and take the others down with it.
• Use WP-CLI for updates where you can (wp plugin update --all). It runs from the command line, without the hard timeout a browser-triggered request has, so it’s far less likely to get cut off partway through.
• If your host allows it, bump max_execution_time and memory_limit a bit for your PHP version, especially on shared hosting with conservative defaults. Both of those live alongside the other settings I keep an eye on in the wp-config.php tweaks I make on every install.
• Take a quick backup, or at least a database snapshot, before any major core update. It won’t fix a stuck maintenance file directly, but a stuck update is sometimes a symptom of a deeper compatibility problem you’ll want to roll back from — testing the update on a copy of your site first is even better, which is exactly what a staging site is for.

One last thing worth knowing: you can deliberately create this same .maintenance file yourself to put your site into maintenance mode for planned work. I don’t actually recommend it, though — the message it shows is bare and unbranded, with no way back in for you while it’s up. A proper maintenance-mode plugin gives you a real page and a way to whitelist your own IP while you work.

Frequently Asked Questions About the Stuck Maintenance Screen

Is my site actually broken, or is this normal?

Your site isn’t broken in the sense of lost data or corrupted files. The maintenance screen is a deliberate safety feature that just failed to turn itself off. Once you delete the one file causing it, your site typically comes back exactly as it was before the update started.

Do I need a developer to fix this?

Not necessarily. Deleting .maintenance only requires access to your site’s files through FTP or your host’s File Manager, both of which involve finding one file and deleting it. If you’re not comfortable logging into your hosting account or don’t have those login details, that’s the point where getting a developer or your host’s support team involved makes sense.

Will I lose any content if I delete the file?

No. The .maintenance file has nothing to do with your posts, pages, or database — it’s purely a flag WordPress checks before loading anything. Deleting it removes the maintenance message and nothing else.

What if the site goes straight back into maintenance mode after I delete the file?

That usually means something is still trying to run the failed update in the background, most often a stuck auto-update retrying on its own schedule. Check Dashboard → Updates for anything mid-progress, and consider turning off auto-updates for that specific plugin temporarily while you sort out why it’s failing.

How do I know if this is even my problem to fix, or my host’s?

If you can log into FTP, SFTP, or your host’s File Manager yourself, it’s a two-minute fix you can do without any coding knowledge. If your hosting plan doesn’t give you file access at all, or you’re not sure how to get it, that’s a support ticket to your host rather than a job for a developer.

Can this happen again even after I fix it?

Yes, if the underlying cause — a timeout, a plugin conflict, an interrupted connection — isn’t addressed. That’s why the “avoiding it next time” habits above matter more than the fix itself; the deletion is a five-minute patch, but preventing the next occurrence takes a few small changes to how you update.

Once you’ve deleted the file and confirmed your updates actually completed, there’s nothing more to do. It’s a small scare with a small fix — just one most people don’t expect the first time it happens.