Will deleting the .maintenance file break my site or lose data?

No. It's just a flag file WordPress uses to show the maintenance screen — it has no connection to your database, media, or content. Deleting it simply tells WordPress the update is over.

Why can't I see the .maintenance file in File Manager?

Files starting with a dot are hidden by default. In cPanel File Manager, click Settings (top right) and enable 'Show Hidden Files (dotfiles)', then refresh the folder view.

I deleted the file but the site is broken now — what happened?

This means the interrupted update left some plugin or core files in a partial state, not just the lock file. Check the PHP error log for a fatal error and reinstall or update the affected plugin/theme fresh.

How long should the maintenance screen normally last?

A few seconds to maybe a minute for a large update. Anything longer than 2-3 minutes almost always means the process was interrupted and the .maintenance file needs to be removed manually.

Can I prevent this on auto-updates that run while I'm asleep?

Yes — make sure your PHP memory_limit and max_execution_time aren't set too low, and keep WordPress core auto-updates on minor releases only. If you run scheduled updates via WP-CLI cron jobs, they're less prone to this than browser-triggered updates since there's no tab that can be closed mid-request.

Is it safe to just delete the .maintenance file?

Yes. It's a tiny flag file with no content that matters - it only tells WordPress to show the maintenance message. Deleting it doesn't affect your database, themes, or plugin files.

Will deleting the file undo the plugin update?

No. It only removes the maintenance-mode flag. If the update itself didn't finish, you may need to re-run it from Plugins > Updates once the site is back online.

The file keeps reappearing every time I delete it - what's going on?

An update is stuck in a retry loop, usually from a failing auto-update via WP-Cron. Disable auto-updates for the plugin involved, clear the file once more, and update it manually instead.

Can I prevent this without SSH access?

Yes. Update plugins one at a time rather than in bulk, avoid closing the browser tab mid-update, and raise WP_MEMORY_LIMIT in wp-config.php if your site runs memory-heavy plugins like WooCommerce.

Fix WordPress Stuck in Maintenance Mode

You clicked "Update" on a plugin or WordPress core, and now every page on the site just shows: "Briefly unavailable for scheduled maintenance. Check back in a minute." Except a minute has turned into twenty, and it's still there. This is one of the most common panic-inducing WordPress errors, and it's also one of the easiest to fix once you know where WordPress hides the lock file causing it.

Symptom: the maintenance screen won't go away

Every front-end and back-end request — including /wp-admin/ — returns the same plain white page with that maintenance message and an HTTP 503 status. It usually shows up right after:

Updating a plugin or theme from the wp-admin dashboard
Running a WordPress core update
Running wp core update or wp plugin update --all over SSH/WP-CLI
An auto-update that ran overnight and never finished

Normally this screen appears for a second or two while WordPress swaps files, then disappears on its own. When it sticks around, something interrupted the update mid-way and left evidence behind.

Cause: WordPress didn't delete its own lock file

Whenever WordPress starts an update, it drops a file called .maintenance in your site's root directory (the same folder as wp-config.php). That file is the entire mechanism behind the message — WordPress checks for it on every request and, if it exists, shows the maintenance screen instead of loading your site. Once the update finishes successfully, WordPress deletes the file itself.

The problem is that step two doesn't always happen. Common triggers:

Trigger	Why it leaves the file behind
Request timeout / low PHP `max_execution_time`	The update process gets killed by the server before cleanup runs
Closing the browser tab during an update	WordPress never gets the follow-up request that triggers cleanup
Server resource limits (low RAM on a shared plan)	PHP process is OOM-killed mid-update
File permission issues	WordPress can create the lock file but can't remove it
A plugin conflict during the update hook	PHP fatal error stops execution before the cleanup step

None of this touches your database, your theme, or your content — it's purely a leftover flag file. That's good news: the fix is safe and takes under a minute.

Fix: delete the .maintenance file

You have three ways in, depending on what access you have.

Option 1: cPanel File Manager

Log in to cPanel and open File Manager
Navigate to public_html (or the subfolder your WordPress install lives in)
Make sure Show Hidden Files (dotfiles) is enabled under Settings — .maintenance starts with a dot, so it's hidden by default
Find .maintenance, right-click it, and delete it
Reload your site — it should load normally right away

Option 2: FTP / SFTP

Connect with FileZilla or any SFTP client, enable “show hidden files” in the client settings, browse to your WordPress root, and delete .maintenance the same way.

Option 3: SSH (fastest if you have terminal access)

cd /home/yourcpanelusername/public_html
ls -la | grep maintenance
rm .maintenance

If you manage WordPress with WP-CLI, there's also a dedicated command that does the same thing safely:

wp maintenance-mode deactivate --path=/home/yourcpanelusername/public_html

Refresh the site. If it loads immediately, that confirms the lock file was the only issue — no further action needed.

If deleting the file doesn't fix it

Occasionally the underlying update genuinely failed partway through, not just the cleanup step. After removing .maintenance:

Check Plugins → Installed Plugins for anything showing as inactive or a version mismatch, and update it manually
Compare your WordPress version under Dashboard → Updates against the latest release — if core update was interrupted, re-run it
Look at wp-content/debug.log (or your PHP error log in cPanel's Errors tool) for a fatal error timestamp matching when the maintenance screen appeared
If a specific plugin's files look incomplete, reinstall it fresh from the WordPress repo or your license source rather than trying to patch it

Prevention: stop this from happening again

A few habits make this a non-issue going forward:

Update plugins and core one at a time, not in a giant batch — it's easier to spot which one caused a problem, and each update finishes faster
Raise PHP's execution time and memory limit if your plan runs on tight defaults. In cPanel, use MultiPHP INI Editor and bump max_execution_time to at least 120 and memory_limit to 256M
Take a backup before major updates — cPanel's backup tool or a plugin like UpdraftPlus, so a bad update is a five-minute rollback instead of a fire drill
Avoid updating over an unstable connection — if the browser tab that started the update loses its request mid-flight, WordPress never gets to run cleanup
Use WP-CLI for bulk updates on a VPS — it runs server-side and isn't tied to a browser tab staying open

If this keeps happening on the same site every time you update, it's usually a sign the hosting plan is underpowered for the update process (low memory or CPU throttling) rather than a WordPress bug — worth a quick resource check with your host.

WordPress Stuck on "Briefly Unavailable for Scheduled Maintenance"