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
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
