If your site shows “Briefly unavailable for scheduled maintenance. Check back in a minute.” and has been saying so for rather longer than a minute, the standard advice is right: delete the file called .maintenance from the WordPress root folder. It takes about thirty seconds and the site comes back.
What the standard advice leaves out is that WordPress ignores that file after ten minutes on its own. Which means that if you have been stuck for a quarter of an hour, the file is not what is holding the site down — and deleting it is treating a symptom you have not identified yet. Two things follow from that, and both matter more than the deletion.
The file is a timestamp with an expiry date, not a switch
When WordPress updates a plugin, a theme or core, it puts the site behind a holding page first. The mechanism is one file. WP_Upgrader::maintenance_mode() — “creates/deletes the maintenance file to enable/disable maintenance mode” — writes .maintenance into the WordPress root, and the entire contents are this:
<?php $upgrading = 1786700000; ?>One variable, holding the Unix timestamp of the moment the update started. No status, no flag, no message. When the update finishes, the same method deletes the file.
Here is the part almost no guide mentions. WordPress does not ask whether the file exists. It asks how old the timestamp inside it is:
// wp_is_maintenance_mode(), in wp-includes/load.php
require ABSPATH . '.maintenance';
// Don't enable maintenance mode if the file is more than 10 minutes old.
if ( ( time() - $upgrading ) >= 10 * MINUTE_IN_SECONDS ) {
return false;
}Ten minutes — 600 seconds — and the block lapses by itself, with the file still sitting there. Core assumes that an update which has not finished in ten minutes never will, and stops punishing your visitors for it. Delete the file if you like, but WordPress had already stopped reading it.
While the block is live, WordPress is well behaved about it. The holding page is served with an HTTP 503 and a Retry-After: 600 header, which is the correct way for a server to say “temporarily unavailable, try again in ten minutes” rather than “this page is gone”. That is why a normal update costs you nothing in search: it announces itself properly and it expires.
Deleting it: the fix, and the part people miss
Do it anyway — a stale .maintenance is clutter, and if the timestamp is somehow in the future it is genuinely the cause. Three steps:
- Connect over FTP/SFTP, or open your host’s file manager, and go to the WordPress root — the folder that contains
wp-config.php,wp-adminandwp-content. - Turn on hidden files. The leading dot makes
.maintenanceinvisible by default. In FileZilla: Server → Force showing hidden files. In cPanel File Manager: Settings → Show Hidden Files. This single setting is why so many people report that the file “is not there”. - Delete
.maintenance, then reload the site in a private window.
If the site returns, skip to the unfinished update, because that is now your actual problem. If it does not return, the file was never the cause and you need the next two sections.
How long has it been stuck? That is the diagnosis
Duration is the single most useful piece of information here, and it is the one nobody asks for. The ten-minute rule turns a vague symptom into a decision tree.
| How long, and what you see | What it means | What to do |
|---|---|---|
| Under 10 minutes, WordPress’s own wording, an update is running | Nothing is wrong. This is the feature working | Wait. Do not close the tab, do not start deleting files mid-update |
| Over 10 minutes, still WordPress’s exact wording | The timestamp is not in the past — a wrong server clock, or a file recreated by hand | Delete .maintenance, then check the server date with your host |
| Over 10 minutes, a branded or styled “coming soon” page | A plugin, not core. Its switch is in the database and never expires | Deactivate that plugin by renaming its folder in wp-content/plugins |
| Over 10 minutes, a maintenance page that is neither of the above | A wp-content/maintenance.php drop-in, or a rule at server level | Rename the drop-in. If there is none, ask the host what is in front of the site |
| The file is gone, the site is up, but pages error or look wrong | The update stopped partway. The file was hiding it, not causing it | Finish the update — see below |
| No maintenance wording at all, just an error | Different problem wearing a similar coat | A 500 has its own diagnosis in the 500 internal server error guide; a fatal shows the WordPress critical error screen |
Four different things put a site “in maintenance”
“Maintenance mode” is one phrase covering four unrelated mechanisms. They live in different places and only one of them switches itself off, which is why generic instructions work for some people and not others.
| Mechanism | Where the state lives | Expires on its own? | How you turn it off |
|---|---|---|---|
| Core update lock | .maintenance, a file in the site root holding a timestamp | Yes — ignored after 10 minutes | It lapses by itself; delete the file to tidy up |
| Custom maintenance page (drop-in) | wp-content/maintenance.php, a file you or a plugin added | No — but it only styles the page, it does not trigger the block | Rename or remove the file |
| Coming-soon / maintenance plugin | An option in the database, plus the plugin itself | No — it stays until someone switches it off | Turn it off in wp-admin, or rename the plugin folder over FTP |
| Host or server-level maintenance | Server configuration, in front of WordPress | No | Only your host can lift it. WordPress cannot see it at all |
The practical shortcut: read the page, not the URL. Core’s holding page is unstyled, black text on white, one sentence. Anything with your logo on it, a countdown, or a newsletter box is a plugin — and no amount of deleting .maintenance will move it.
If the site comes back, the update did not finish
This is the half of the job that gets skipped, because the visible problem is already gone. The file was written by an update. If removing it brought the site back, that update stopped somewhere in the middle — usually a closed browser tab, a dropped connection, a PHP timeout, or too many plugins updated at once.
Four checks, in order, and none of them takes long:
- Visit
/wp-admin/upgrade.php. If WordPress asks to update the database, run it. That prompt means core files were replaced but the schema was not migrated. - Open Dashboard → Updates and look at what is still pending. Whatever was being updated when it stopped is usually still listed. Update it again, one item at a time.
- Check
wp-content/upgrade/. Leftover folders in there are the unpacked files of an update that never completed. They are safe to delete once the update has been re-run successfully. - Click through the site as a visitor and, if it is a shop, place a test order. A plugin left half updated tends to fail in one specific place rather than everywhere, which is exactly the kind of breakage that goes unnoticed for a fortnight.
When it is not worth fixing it yourself
Most of the time this is a job for you, and paying anyone for it would be strange. Deleting a file with one line in it and re-running an update is not specialist work, and any studio that dresses it up as one is selling you the thirty seconds rather than the skill.
Two situations change that. The first is when the site does not come back after the file is gone: at that point maintenance mode was never the problem, you are looking at a broken update, and continuing to delete things is how people lose a working install. The second is a shop or a booking site, where the stakes sit in the half-finished update rather than in the holding page. A payment or booking plugin stopped mid-upgrade can take orders and mishandle them quietly, which is worse than being visibly down, because nobody notices for days.
And if this keeps happening — updates that stall every month, timeouts on every batch — the maintenance page is a symptom of an environment that cannot finish the work: an old PHP version, a host that kills long requests, or plugins that no longer match either. That is worth fixing once, properly, rather than deleting a file every few weeks. It is what our WordPress error-fixing service does: back up, find why the update dies, fix that, and leave the rest alone.
Frequently asked questions
Where exactly is the .maintenance file, and why can I not see it?
It sits in the WordPress root — the same folder as wp-config.php, wp-admin and wp-content. You cannot see it because the leading dot makes it a hidden file, and almost every FTP client and hosting file manager hides those by default. In FileZilla it is Server → Force showing hidden files; in cPanel File Manager it is Settings → Show Hidden Files (dotfiles). People conclude the file is not there, when in fact it was never displayed.
Is it safe to delete the .maintenance file?
Yes, deleting the file itself cannot damage anything: it contains one line with a timestamp and nothing else. What is not safe is assuming that deleting it finished the job. The file was written because an update started, so if removing it brings the site back, an update stopped partway through and still needs completing. Take a backup before you touch anything, out of habit rather than fear.
My site has been in maintenance mode for hours. Is that normal?
No, and it is not core doing it. WordPress ignores its own maintenance file once the timestamp inside it is more than ten minutes old, so a block that outlasts ten minutes is coming from somewhere else: a coming-soon or maintenance plugin whose switch lives in the database, a wp-content/maintenance.php drop-in, a server clock that is wrong, or a .maintenance file someone recreated by hand. Read the page you are seeing — if it is branded or styled, it is a plugin, not WordPress.
Does maintenance mode hurt my SEO?
Not at the length it is designed for. WordPress answers with a 503 status and a Retry-After: 600 header, which is exactly the correct way to say "temporarily unavailable, come back in ten minutes". The risk starts when it lasts. Google states that "any content Google receives from URLs that return a 5xx status code is ignored", that crawlers "temporarily slow down with crawling", and that already indexed URLs are "preserved in the index, but eventually dropped". Ten minutes is invisible. Ten days is not.
How do I avoid getting stuck again?
Most cases come from updating several plugins at once, on a browser tab that was then closed or lost connection — the update stops mid-run and nothing removes the file. Update in small batches, leave the tab alone until it finishes, and do the big ones on staging first. If updates keep breaking, the real problem is usually an outdated PHP version or a plugin that no longer matches it, not bad luck.
The site is back but wp-admin asks me to update the database. Should I?
Yes. That prompt means core files were replaced but the database schema was not migrated, which is exactly the half-finished state the maintenance file was covering. Run it — it is normally a single click at /wp-admin/upgrade.php and it takes seconds. Ignoring it leaves the site running new code against an old schema, which produces errors that look unrelated and are very hard to trace back to this afternoon.
Sources (all verified August 2026): WordPress Developer — WP_Upgrader::maintenance_mode(); WordPress Developer — wp_is_maintenance_mode(); WordPress Developer — wp_maintenance(); Google Search Central — HTTP status codes and network errors; MDN — 503 Service Unavailable.