When WordPress shows "Briefly unavailable for scheduled maintenance. Check back in a minute," delete the .maintenance file in the site root and the site comes back immediately:
rm /var/www/html/.maintenanceThat single dotfile is the entire cause. WordPress writes it at the start of every core, plugin, or theme update, and removes it when the update finishes. If the update was interrupted (a PHP timeout, a fatal error, a closed browser tab mid-upgrade, a hosting process kill), the file never gets deleted and the whole front end and admin stay locked behind the maintenance message.
Why the page is stuck
The mechanism is in WordPress core. Before an update starts, the upgrader writes a file named .maintenance to the install root with a single line of PHP setting $upgrading to the current Unix timestamp. On every request, wp_maintenance() runs early and calls wp_is_maintenance_mode(), which reads that file. If the file exists and the timestamp is less than 10 minutes old, WordPress serves the maintenance HTML and exits before rendering anything else.
So two things have to be true for you to see the message:
- The
.maintenancefile exists in the site root. - Its timestamp is within the last 600 seconds.
That 10-minute window is why the message sometimes clears on its own: once the timestamp ages past 600 seconds, wp_is_maintenance_mode() treats the marker as stale and lets the site render again. But the file is still sitting there, and the next update will overwrite it with a fresh timestamp, so "it fixed itself" is not a fix. Delete the file.
Delete the file
The file is a dotfile (leading dot), so it is hidden from a plain ls. List it explicitly:
ls -la /var/www/html/.maintenance-rw-r--r-- 1 www-data www-data 26 Mar 30 09:12 /var/www/html/.maintenance
Then remove it:
rm /var/www/html/.maintenanceReload the site. It should render immediately, no cache clear, no restart needed.
Your site root is wherever wp-config.php and wp-load.php live. On a stock Apache or nginx box that is often /var/www/html; on managed hosting it might be ~/public_html or ~/htdocs. The .maintenance file sits in that same directory, alongside wp-admin/ and wp-content/.
No shell access? Use FTP or the file manager
If you are on shared hosting with no SSH, connect over SFTP/FTP or open the host's file manager, navigate to the site root, and delete .maintenance. The one thing to watch: most FTP clients and file managers hide dotfiles by default. In FileZilla it is Server → Force showing hidden files; in cPanel File Manager it is the Settings toggle for "Show Hidden Files (dotfiles)." Without that, the file is there but invisible and you will swear the directory is clean.
What you actually see
The message is plain, unstyled HTML that WordPress hardcodes in wp_maintenance(). No theme, no header, no footer, just:
Briefly unavailable for scheduled maintenance. Check back in a minute.
Both the front end and /wp-admin show it, which is what makes it feel like the whole site is down. It is not down; the files and database are fine. WordPress is deliberately short-circuiting every request until the marker file is gone.
A nicer maintenance page (optional)
If you drop a file named maintenance.php into wp-content/, WordPress loads that instead of the bare one-liner whenever maintenance mode is active. This is the supported way to brand the page (the wp_maintenance() function checks for WP_CONTENT_DIR/maintenance.php before falling back to the default). A minimal version:
<?php
http_response_code(503);
header('Retry-After: 600');
?>
<!doctype html>
<html lang="en">
<head><meta charset="utf-8"><title>Updating</title></head>
<body>
<h1>We are applying updates</h1>
<p>The site will be back in a minute. Thanks for your patience.</p>
</body>
</html>Returning 503 Service Unavailable with a Retry-After header is the correct signal here: it tells search engine crawlers the outage is temporary so they do not deindex the page. The default WordPress maintenance response does send a 503 already, so a stuck .maintenance file is not a long-term SEO problem unless it stays stuck for days.
Stop it from happening again
The leftover file is a symptom. The update failed partway through, usually for one of these reasons:
| Cause | Symptom | Fix |
|---|---|---|
PHP max_execution_time too low | Large update times out mid-write | Raise to 120s+ in php.ini or via host panel |
| Memory exhaustion | White screen during update, then stuck | Raise WP_MEMORY_LIMIT / PHP memory_limit |
| Updating many items at once | Bulk plugin update dies on one item | Update plugins one at a time |
| Closed the tab mid-update | Browser-driven update never finished | Let updates run to completion |
| Disk full | Update can't write, leaves marker | Free space, then delete .maintenance |
After deleting .maintenance, finish the job WordPress abandoned. Re-run the update that failed, because an interrupted core update can leave the database schema and the files out of step. The cleanest way is WP-CLI, which does not depend on a browser tab staying open:
wp core update
wp plugin update --all
wp theme update --allIf wp core update reports you are already on the latest version but the site behaves oddly, force the file refresh:
wp core update --forceToggle maintenance mode on purpose
If you want maintenance mode deliberately (not the accidental stuck kind), WP-CLI manages the same marker file cleanly:
wp maintenance-mode activate
wp maintenance-mode status
wp maintenance-mode deactivateactivate writes the .maintenance file with the current timestamp; deactivate removes it. This is the right tool when you are about to do manual surgery on the database or files and want the site to show the maintenance page on purpose. It saves you from hand-creating and hand-deleting the dotfile, and status tells you whether the marker is currently present.
See also
- Fix the WordPress "Call to undefined function get_option()" Fatal Error: another bootstrap-level failure, this one from
wp-load.phpnot running, that locks you out the same way a stuck maintenance file does - How to Change a WordPress Password: the four reliable reset methods, including the direct-database edit you reach for when an update leaves you locked out of
/wp-admin - PHP Memory Limit: How to Fix "Allowed Memory Size Exhausted": if updates keep dying mid-write and leaving the marker behind, the memory ceiling is usually what kills them
- Using AI with WP-CLI for Faster WordPress Operations: the wider WP-CLI workflow for running core and plugin updates without a browser tab, so an interrupted upgrade never strands the site again
- "Error Establishing a Database Connection" Stuck in Cache: the other "the site looks down but it is fine" trap, where a cache keeps serving the database-error page after the database has recovered
In your WordPress site root, the same directory as wp-config.php, wp-load.php, wp-admin/, and wp-content/. On a stock server that is often /var/www/html; on shared hosting it may be public_html or htdocs.
It is a hidden dotfile, so a plain ls or a default FTP listing will not show it. List with ls -la or enable "show hidden files" in your FTP client or host file manager.
The message stops showing once the timestamp inside the file is more than 600 seconds (10 minutes) old, because wp_is_maintenance_mode() treats the marker as stale. But the file itself stays on disk.
That is not a real fix. The next update overwrites the file with a fresh timestamp and the message returns. Delete the file to be done with it.
Yes. It is a transient marker WordPress writes at the start of an update and deletes when the update finishes. Removing it only tells WordPress the update is no longer in progress.
The caveat is that the file existing means an update was interrupted. After deleting it, re-run the failed update (for example wp core update or a plugin update) so the files and database schema do not stay out of step.
The update process died before it reached the line that deletes the marker file, so the file was left behind with a timestamp newer than 10 minutes old. Common triggers are a PHP max_execution_time timeout, memory exhaustion, or closing the browser tab partway through a browser-driven update.
Delete .maintenance, then address the underlying cause (raise PHP limits, update one plugin at a time) before retrying.
Not for a brief stuck file. WordPress serves the maintenance page with an HTTP 503 Service Unavailable status, which tells crawlers the outage is temporary and to come back later, so a few minutes or hours of it does no ranking harm.
It only becomes a risk if the file stays stuck for days and Google keeps hitting a 503 on every URL. Delete .maintenance promptly and there is nothing to worry about. For a planned outage, see the custom maintenance page above, which keeps the correct 503 while branding the page.
Yes. Run wp maintenance-mode activate to put the site into maintenance mode and wp maintenance-mode deactivate to bring it back. wp maintenance-mode status reports whether the marker is currently present.
WP-CLI writes and removes the same .maintenance file, so it is the clean way to toggle the page on purpose before doing manual database or file work.
Sources
Authoritative references this article was fact-checked against.
- wp_maintenance(): WordPress Developer Referencedeveloper.wordpress.org
- wp_is_maintenance_mode(): WordPress Developer Referencedeveloper.wordpress.org
- wp maintenance-mode: WP-CLI Command Referencedeveloper.wordpress.org
