Errors
WordPress Stuck in Maintenance Mode: Fix It Fast
WordPress gets stuck in maintenance mode when an update is interrupted before it finishes — the fix is almost always deleting a single hidden file called .maintenance from your site's root folder. The whole process takes about two minutes if you know where to look. This guide walks you through every scenario, including the ones where deleting that file isn't enough.
What You're Seeing
Your site is displaying this message on every page — front end and admin:
Briefly unavailable for scheduled maintenance. Check back in a minute.
It's been there for ten minutes. Or an hour. Or you came back the next morning and it's still there. Refreshing doesn't help. Clearing your browser cache doesn't help. The site is locked for every visitor, not just you.
If instead you're seeing a white screen, a critical error notice, or a "there has been a critical error on this website" message, the update finished but something broke — that's a different problem. See the critical error fix guide or the white screen fix guide for those.
Why This Happens
Every time WordPress runs an update — whether it's a plugin, a theme, or core itself — it creates a file named .maintenance in your site's root directory. That file is a flag: it tells WordPress to serve the maintenance screen while files are being swapped out. When the update completes successfully, WordPress deletes the file and your site comes back.
The file gets left behind when the update process is interrupted mid-flight. Common causes:
- A PHP timeout — the server hit its execution time limit while downloading or unpacking a large plugin or core update.
- A memory limit hit — WordPress ran out of allocated PHP memory during the update.
- A lost server connection — your browser tab closed, your laptop went to sleep, or a brief network drop cut the FTP/HTTP connection mid-update.
- A permissions error — WordPress couldn't finish writing updated files, so the process died partway through.
- Running multiple updates at once — selecting "Update All" in the dashboard kicks off parallel processes that can step on each other, especially on shared hosting with tight resource limits.
None of these causes are your fault, and none of them mean your site is broken beyond repair. The fix is usually trivial.
Step 1: Delete the .maintenance File
Before touching anything, take a quick backup if your host makes that easy — some control panels offer a one-click snapshot. If that's not available, proceed anyway; this step is low-risk.
Connect to your site via FTP or your host's File Manager (cPanel, Plesk, or equivalent). Navigate to your WordPress root — the folder that contains wp-admin, wp-content, and wp-config.php. Look for a file named .maintenance.
You may need to enable hidden files. Files beginning with a dot are hidden by default in most FTP clients and file managers. In FileZilla: Server → Force Showing Hidden Files. In cPanel File Manager: click Settings (top right) and check Show Hidden Files.
Once you can see it, delete .maintenance. Reload your site. In the vast majority of cases, that's the entire fix.
Step 2: Verify the Update Actually Completed
Deleting the file brings your site back, but it doesn't tell you whether the update that was interrupted finished successfully. A half-updated plugin or theme is a real problem — it can cause errors, white screens, or subtle breakage that only shows up later.
Log in to Dashboard → Updates. If the plugin, theme, or core version that was updating still shows as needing an update, it didn't finish. Run it again — this time on its own, not as part of a bulk update.
If re-running the update fails again, note the error message. A PHP memory error looks like Fatal error: Allowed memory size of ... exhausted. A timeout looks like a blank screen or a "the connection was reset" browser error. Both are solvable (see the prevention section below), but they need fixing before the update will succeed.
Step 3: If the File Keeps Coming Back
If you delete .maintenance, your site comes back, but then falls into maintenance mode again the next time you run any update, the interruption cause is still present. Common culprits:
PHP Memory Limit Is Too Low
WordPress needs enough memory to download, unpack, and swap in new files. Many shared hosts default to 64 MB or 128 MB, which can be tight for large plugins. Add this line to your wp-config.php (above the /* That's all, stop editing! */ line) to request more memory from PHP:
define( 'WP_MEMORY_LIMIT', '256M' );
Note: this only works up to whatever ceiling your host allows. If your host caps PHP memory below 256 MB, you'll need to raise the limit in your hosting control panel's PHP settings, or contact support.
PHP Execution Timeout Is Too Short
Large plugin or core updates can take 20–60 seconds to download and unpack on a slow server. If your host's max_execution_time is set to 30 seconds, the process gets killed mid-update. You can try adding this to wp-config.php:
set_time_limit( 300 );
On many shared hosts, this is overridden by the server configuration and won't help — in that case, contact hosting support and ask them to raise max_execution_time to at least 120 seconds for your account.
File Permission Issues
WordPress needs write access to wp-content and its subdirectories to install updates. Standard correct permissions are 755 for directories and 644 for files. If these have drifted (often after a migration or a server reconfiguration), updates will fail partway through. Most hosting control panels let you reset permissions recursively — or you can do it via SSH:
find /path/to/wordpress -type d -exec chmod 755 {} \;
find /path/to/wordpress -type f -exec chmod 644 {} \;
If you're unsure of your site's exact path, ask your host. And if SSH commands make you nervous, this is a good place to get a second pair of eyes on things.
Step 4: What to Do If the Half-Updated Plugin Broke Something
If after deleting .maintenance your site is back but something is broken — pages won't load, the admin panel errors out, or a specific feature is dead — the interrupted update left plugin or theme files in a partial state. The safest recovery path is:
- Restore from your most recent backup, which takes you to a working state before the failed update.
- Then re-run the update, this time after confirming your PHP memory and timeout limits are adequate.
If you don't have a recent backup, you can try manually uploading a fresh copy of the plugin's files via FTP (download from WordPress.org, overwrite what's on the server), but this requires confidence with file management. If the broken component is WordPress core itself, the broke after update fix guide covers that scenario in depth.
How to Prevent This in the Future
A few habits eliminate most stuck-maintenance-mode incidents:
- Update plugins one at a time. Bulk updates on resource-constrained hosting is the single biggest trigger. It takes a few extra minutes and dramatically reduces failures.
- Always back up before updating. Automated daily backups stored off-site mean any failure is recoverable in minutes. If you're not set up with that, it's worth fixing — see Mend's Care Plan which includes managed backups alongside updates and monitoring.
- Keep PHP up to date. Older PHP versions are slower and have lower default limits. Running PHP 8.1 or 8.2 means more headroom and faster update processing. The guide on upgrading PHP for WordPress covers how to do this safely.
- Check your server resource limits before updating large plugins or core versions — memory and timeout limits are visible in most hosting control panels under PHP settings.
When to Call a Professional
Most maintenance-mode lockouts are solved by deleting one file. But if you've deleted .maintenance and your site is still broken, if the update keeps failing, if you're uncomfortable with FTP or server settings, or if a partial update left your site in an error state — those are good reasons to hand it off.
Mend's Quick Fix service covers exactly this kind of problem: a senior engineer diagnoses the root cause, does any necessary file and database cleanup, verifies the updates all complete cleanly, and sends you a plain-English summary of what happened and what changed — usually the same day. If you're not sure what you're dealing with, a free diagnosis will triage it and give you a flat price before any work starts.
Maintenance mode lockouts feel alarming because your entire site goes dark, but they're almost always resolved in under five minutes once you know what to delete. The key is understanding the file behind the curtain — and making sure the update that caused it actually finishes successfully before you move on.
Frequently asked questions
How do I access the .maintenance file if I can't log into WordPress admin?
The .maintenance file lives in your site's root directory on the server — you access it via FTP (FileZilla is free and works well) or your hosting control panel's File Manager, not through WordPress itself. You don't need admin access to delete it.
Is it safe to delete the .maintenance file?
Yes. Deleting it only removes the flag that triggers the maintenance screen. It doesn't affect your database, your content, or any plugin or theme files. The only risk is if an update was still genuinely running (which almost never happens — updates that stall are dead, not paused).
Can WordPress get stuck in maintenance mode without me running an update?
Rarely, but yes. Automated background updates — which WordPress runs for minor core releases and security patches — can also leave the file behind if they're interrupted. If you see the maintenance screen without having started an update yourself, check for a recent auto-update in Dashboard → Updates → Update History (if logged in) or look at the file's timestamp on the server.
Why does my site show maintenance mode to visitors but not to me?
It shouldn't — maintenance mode is supposed to affect everyone. If you're bypassing it, you're likely seeing a cached version of your site delivered by your browser, a CDN, or a server-level cache. Your visitors are still seeing the maintenance screen. Delete the .maintenance file and then flush your cache to make sure everyone gets the live site.