Key facts at a glance
WordPress maintenance mode in 2026
Last updated
- What the message is
Briefly unavailable for scheduled maintenance. Check back in a minute.A 503 Service Unavailable page WordPress shows automatically while it updates its core, a plugin, or a theme.- The mechanism
- WordPress creates a
.maintenancefile in the site root holding a single timestamp. While it exists, only a dozen core files load, no plugins, no theme, no database. WordPress deletes it when the update finishes. - Why it gets stuck
- An interrupted update: closing the updates screen mid-run, a server timeout, low PHP memory, or a bulk update that did not finish. The file is never removed, so the maintenance page stays.
- The immediate fix
- Delete the
.maintenancefile from the site root over SFTP, the file manager, or WP-CLI, then reload. It is a temporary flag, so deleting it is safe and restores the site in most cases. - The 10-minute rule
- WordPress is built to exit maintenance after 10 minutes on its own: once
(time() - $upgrading) >= 600seconds it ignores the file and loads normally. So a site stuck beyond 10 minutes has a second cause, almost always a cache. - After you delete it
- If the site loads, you are done, but still resolve why the update stalled. If you get a white screen instead, the interrupted update left a plugin or theme broken, and you move to the debug log. If the file keeps coming back, a failing auto-update is recreating it, so finish or roll back that update to stop the loop.
Source: the WordPress developer reference for maintenance mode, the WP-CLI maintenance-mode command documentation, the WordPress common errors documentation, and our hands-on repairs. Get a quote in 60 seconds →
What maintenance mode actually is
WordPress maintenance mode is a safety feature, not a fault. Every time WordPress updates its core, a plugin, or a theme, it does not want visitors loading the site while files are being swapped out underneath them, because a half-replaced plugin could throw errors. So at the start of the update it writes a small file named .maintenance into your site root, the same folder that holds wp-config.php. That file contains nothing but a single line setting a timestamp, the moment maintenance began.
While that file is present, WordPress short-circuits its normal loading. It does not load your plugins, your theme, your translations, or even connect to the database. It loads only a dozen or so core files and returns a plain page with a 503 Service Unavailable status and the line Briefly unavailable for scheduled maintenance. Check back in a minute. This is deliberately minimal so it cannot itself break. In a normal update this lasts a second or two. The update finishes, WordPress deletes the .maintenance file as its final step, and the site returns to normal. Most site owners never even see the page.
The problem is only ever that the file did not get deleted. If the update stops before it reaches the cleanup step, the flag stays, and WordPress keeps showing the maintenance page to everyone because, as far as it can tell, an update is still in progress. Nothing is corrupted, nothing is lost. WordPress is simply waiting for an update that already stopped. That framing is what makes the fix so direct: you are not repairing damage, you are removing a flag that was left up by accident.
The immediate fix
Delete the .maintenance file from your site root. There are two ways, depending on what access you have.
Option 1: SFTP or the hosting file manager
- Connect with an SFTP client like FileZilla or Cyberduck, or open your host file manager.
- Turn on hidden files, since the leading dot makes
.maintenancehidden by default. In FileZilla this is Server then Force showing hidden files. - Open the WordPress root folder, the one containing
wp-config.phpandwp-login.php. - Delete the file named
.maintenance. - Reload your site.
Option 2: WP-CLI or SSH
If you have SSH access, one command clears it, which is the standard method on managed hosts.
# Turn maintenance mode off
wp maintenance-mode deactivate
# Or simply remove the file from the site root
rm .maintenance<?php $upgrading = 1782835200; ?>That single timestamp is the entire file. It holds no content, settings, or code, which is why removing it is safe.
Which symptom matches yours
Find the row that matches what you see. The file deletion fixes the common case, and the rest point at the second cause.
| Symptom | Most likely root cause |
|---|---|
| Every page shows Briefly unavailable for scheduled maintenance and it will not clear | An interrupted update left the .maintenance file in your site root. Delete that one file over SFTP or with WP-CLI and the site returns. |
| You are still stuck more than 10 minutes after the update stalled | WordPress is designed to exit maintenance after 10 minutes, so a cache or CDN is serving the saved 503 page. Purge every cache and test in incognito. |
| The .maintenance file reappears every time you delete it | A failing auto-update or scheduled task keeps retrying and recreating it. Stop the loop and finish or roll back the underlying update. |
| You deleted the file and now see a white screen or critical error | The maintenance page was hiding a half-finished update. A plugin or theme is now failing. Enable the debug log and fix the broken extension. |
| It happened during a bulk update of many plugins at once | The bulk run timed out partway, common on low-memory hosts. Delete the file, then raise PHP memory and execution time and update one item at a time. |
| The maintenance page returns a 503 to Google and visitors | Expected while genuinely updating, but a stuck 503 left for long can affect crawling. Clear it fast by removing the file and resolving the failed update. |
The five root causes
The first is the cause in most cases. The other four explain the situations where deleting the file is not the whole story.
1. An interrupted update left the .maintenance file behind
This is the classic and most common cause. An update started, created the .maintenance file, and then stopped before it could finish and delete it. The interruption is usually one of: closing or refreshing the updates screen while it was still working, a server timeout on a slow or busy host, the site running out of PHP memory during the update, or a bulk update of many plugins that did not complete in the time available. The leftover file is the entire problem, and deleting it restores the site.
2. A cache is serving the saved 503 page
This is the cause when you are stuck more than 10 minutes, or when deleting the file does not clear the page. WordPress is designed to leave maintenance mode automatically after 10 minutes by checking the timestamp inside the file, so a genuine leftover should self-heal in that window. When it does not, a caching plugin, a host page cache, or a CDN such as Cloudflare has cached the 503 maintenance response and keeps serving it. The page you see is a saved copy, not the live site. Purge every cache layer including the CDN, and test in a private window, because your own browser may also be holding the cached page.
3. A failing auto-update keeps recreating the file
If the .maintenance file reappears after you delete it, an update is actively retrying and failing. WordPress auto-updates and scheduled tasks can re-attempt a broken update on a loop, and each attempt recreates the file before failing again. Deleting it once does not help because the loop just puts it back. The fix is to identify the update that is failing, core, a specific plugin, or a theme, and resolve it: reinstall the latest version cleanly so it completes, or roll it back to the last working version. Temporarily turning off auto-updates while you do this stops the file from returning.
4. The interrupted update actually broke a plugin or theme
Sometimes removing the maintenance flag reveals a white screen or the critical error message rather than your site. That means the update did not just stall, it left a plugin or theme half-updated and broken, and WordPress now hits a fatal error trying to load it. This is no longer a maintenance-mode problem, it is an update-failure recovery. Enable the debug log to see exactly which extension is failing, then reinstall it from a clean copy, replace it, or deactivate it to get the site back. Our debug log guide and critical error guide carry the rest.
5. Low server resources caused the interruption
Underneath many stuck-maintenance cases is a host that could not finish the update. If your PHP memory limit or maximum execution time is low, a larger update, or a bulk update of several extensions, can run out of resources and die partway, leaving the flag behind. Deleting the file gets you running, but the next update will likely stall the same way unless you address the cause. Raising the PHP memory limit and execution time, and updating one item at a time rather than in bulk, removes the interruption at its source.
DIY vs hand it off
Deleting one file is a genuine self-fix for most people. When the file keeps returning, a white screen appears, or you cannot reach your files, handing it off is faster. If the left column matches you can likely do this. If the right column matches, get help.
Realistic on your own
- ✓You can connect over SFTP or open the host file manager
- ✓You can show hidden files and delete the .maintenance file
- ✓The site returns as soon as the file is gone
- ✓Purging your cache and CDN clears a lingering page
- ✓You can raise PHP memory and execution time, or ask the host
- ✓You have a backup before retrying the update
Hand it off, save the time
- ✗The .maintenance file keeps coming back after deletion
- ✗Deleting it reveals a white screen or critical error
- ✗You cannot reach your files over SFTP or the file manager
- ✗A half-finished core update left the database in a strange state
- ✗You depend on the plugin whose update broke and cannot lose it
- ✗The site is a store losing orders every minute it is down
How to diagnose it
The first two steps fix the common case. The rest tell you which second cause you have if it does not clear.
Connect over SFTP or the file manager, enable Show hidden files, and open the folder with wp-config.php. Confirm a file named .maintenance is present. Its existence confirms the diagnosis.
Remove the file, or run wp maintenance-mode deactivate, then reload the site in a private window. If it returns, you are done, just confirm the interrupted update actually finished.
Because WordPress exits maintenance on its own after 10 minutes, a page that persists is usually a cached 503. Purge your caching plugin, host cache, and CDN, then hard refresh or test in incognito.
A returning file means a broken update is retrying. Check Dashboard then Updates if you can reach it, or review recent update activity, to see which core, plugin, or theme update was failing, so you can complete or roll it back.
Enable WP_DEBUG and WP_DEBUG_LOG in wp-config.php, reload, and read wp-content/debug.log. The most recent fatal names the plugin or theme the interrupted update left broken. See our debug log guide.
How to fix it for good
Removing the file gets you online. These steps stop it recurring and resolve whatever the interrupted update left behind.
Complete or roll back the interrupted update
Once the site is back, finish the job the stalled update started. If you know which plugin, theme, or core update was running, reinstall its latest version cleanly so it applies fully, or roll it back to the previous working version. Leaving a half-applied update in place invites a white screen later, so do not skip this.
Clear every cache layer
If a cached 503 was part of the problem, purge the caching plugin, the host page cache, and the CDN, then confirm the live site loads in a private window. Until the cache is cleared, visitors may keep seeing the maintenance page even though your site is fine.
Raise PHP limits so updates can finish
If a resource limit caused the interruption, raise the PHP memory limit and execution time so the next update completes. Add these to php.ini or a .user.ini, or ask your host.
memory_limit = 256M
max_execution_time = 120You can also raise the WordPress memory limit in wp-config.php with define( 'WP_MEMORY_LIMIT', '256M' );.
Update safely from now on
- Never close or refresh the updates screen while an update is running.
- Update one plugin or theme at a time, not everything in one bulk run.
- Keep recent backups so a failed update is a quick restore.
- Test major updates on a staging copy before production.
File keeps returning, or deleting it revealed a broken site?
Let us fix it in 2 hours →A real stuck-maintenance session
A composite from the maintenance-mode repairs we run most weeks, with identifying details removed.
A consultant selected all 14 plugin updates at once, clicked Update, and after a minute of waiting closed the laptop to head to a meeting. The site then showed Briefly unavailable for scheduled maintenance to everyone, including a client who emailed asking if the business had closed. It had been more than an hour.
The site had been stuck well beyond the 10-minute window, which told us two things were happening. We connected over SFTP, enabled hidden files, and found the .maintenance file in the root from the interrupted bulk update. The site also sat behind a CDN that had cached the 503 page, which is why it had not self-cleared. One of the 14 plugins had also been left half-updated.
We deleted the .maintenance file and purged the CDN cache, and the site returned. The half-updated plugin then threw a notice in the debug log, so we reinstalled it cleanly to complete its update. We raised the PHP memory limit, finished the remaining plugin updates one at a time, and confirmed every page loaded. We left the consultant a one-line rule: update plugins one at a time and never close the screen mid-update.
When to stop and hand it off
Four situations where DIY costs more than help. First, the .maintenance file keeps reappearing, which means a failing update is looping and needs to be properly completed or rolled back. Second, deleting the file reveals a white screen, so the interrupted update left a plugin or theme broken and the job is now update-failure recovery. Third, a half-finished core update left the database mid-migration, which needs careful handling to avoid data issues. Fourth, you cannot reach your files at all to delete the flag. We remove the leftover file, clear cached 503 responses, complete or roll back the stalled update, and harden the server so the next update finishes cleanly. Flat $49 to $149, done in two hours when scope fits, money back if we cannot.
WordPress maintenance mode FAQ
What does Briefly unavailable for scheduled maintenance mean?
It is the message WordPress shows while it is updating itself. Whenever WordPress updates its core, a plugin, or a theme, it briefly puts the site into maintenance mode by creating a small file called .maintenance in the site root, and it serves every visitor a simple page that reads Briefly unavailable for scheduled maintenance. Check back in a minute, along with a 503 Service Unavailable status. While that file is present, WordPress loads only a dozen core files, no plugins, no theme, and does not even touch the database, which is why the page is so plain. Normally the update finishes in seconds, WordPress deletes the file automatically, and the site returns. You only have a problem when that file is left behind and the message never goes away.
Why is my site stuck on it instead of clearing in a few seconds?
Because an update was interrupted before it could finish and delete the .maintenance file. The usual triggers are closing or refreshing the updates screen while an update is still running, a server timeout on a slow host, the site running out of PHP memory mid-update, or a bulk update of many plugins at once that did not complete. When the update stops partway, the .maintenance file is never removed, so WordPress keeps thinking an update is in progress and keeps serving the maintenance page to everyone. The site is not broken in a deep sense, it is simply waiting for an update that already gave up. Removing the leftover file tells WordPress the update is over and the site comes straight back.
How do I fix it right now?
Delete the .maintenance file from your site root. Connect with an FTP or SFTP client, your hosting file manager, or SSH, and open the WordPress root folder, the same one that contains wp-config.php and wp-login.php. The file is named .maintenance with a leading dot, which makes it hidden, so you may need to enable Show hidden files in your client first, for example in FileZilla under Server then Force showing hidden files. Delete that one file and reload your site. In the large majority of cases the site returns immediately. If you have WP-CLI or SSH access, a single command does the same thing: wp maintenance-mode deactivate. Deleting the file is safe, because it is only a temporary flag, not part of your site content.
I deleted the file but the site is still showing the maintenance page. Why?
This usually means a cache is serving the saved maintenance page rather than the live site. Here is the useful detail most guides miss: WordPress is actually designed to leave maintenance mode on its own after 10 minutes. Its code checks the timestamp inside the .maintenance file, and once more than 10 minutes have passed it ignores the file and loads the site normally, even if the file is still there. So if your site is still stuck more than 10 minutes after the update stalled, the leftover file is not the only thing keeping you out. The most common second cause is a caching plugin, a host page cache, or a CDN like Cloudflare serving the cached 503 maintenance response. Purge every cache layer, including the CDN, and test in a private or incognito window. Your own browser cache can do the same thing, so a hard refresh helps too.
The .maintenance file keeps coming back after I delete it. What now?
If the file reappears, something is actively re-triggering the update that keeps failing. The common culprit is a WordPress auto-update or a scheduled task that retries the same broken update on a loop, recreating the .maintenance file each time it tries and fails. The fix is to break the loop and resolve the underlying update rather than just deleting the file again. Identify which update was failing, core, a specific plugin, or a theme, and either complete it cleanly by reinstalling the latest version manually, or roll it back to the previous working version. If a failing auto-update is the trigger, temporarily disabling auto-updates while you sort it out stops the file from being recreated. Once the update is resolved, the file stays gone.
I deleted the file and now I get a white screen instead. Did I make it worse?
No, you uncovered the real problem. The maintenance page was hiding a half-finished update. When the update was interrupted, a plugin or theme may have been left in a broken, partially updated state, so once the maintenance flag is removed WordPress tries to load that broken code and hits a fatal error, which shows as a white screen or the critical error message. This is now a standard update-failure recovery: enable the debug log to see exactly which plugin or theme is failing, then update it to a clean copy, replace it, or deactivate it. Our guides on reading the debug log and the critical error walk the rest. The good news is you are past the maintenance flag and onto the actual fix.
How do I stop this from happening again?
Give updates room to finish and do not interrupt them. Three habits prevent almost every recurrence. First, never close or refresh the updates screen while an update is running, let it complete. Second, update one plugin or theme at a time rather than selecting everything and bulk updating, since a long bulk run is far more likely to time out partway. Third, make sure your server has adequate PHP memory and execution time, because an underpowered host that runs out of memory mid-update is a frequent cause of the interruption. Better still, test updates on a staging copy first, and keep recent backups so a failed update is a quick restore rather than an emergency. Healthy update hygiene is what keeps the .maintenance file doing its job and disappearing on its own.
Is it safe to delete the .maintenance file?
Yes. The .maintenance file is a temporary flag WordPress creates only to display the maintenance page during an update, and WordPress deletes it itself the moment a normal update finishes. It contains nothing but a single timestamp marking when maintenance started. It is not part of your posts, settings, theme, or plugins, and removing it cannot harm your content or configuration. The only thing deleting it does is tell WordPress that maintenance is over. The genuine caution is not the file, it is what caused the update to stall in the first place, which you still want to resolve so the update completes and does not leave the site in a half-updated state. Delete the file with confidence, then check that the update it interrupted actually finished.
Sources and further reading
Every claim on this page traces back to the WordPress developer reference, the WP-CLI documentation, or the WordPress common errors documentation.