On Page Navigation
On Page Navigation
Maintenance mode is a holding page. That is the entire feature.
When WordPress runs a core, plugin or theme update, it writes a small file named .maintenance into your web root. While that file exists, logged out visitors get a plain screen saying the site is briefly unavailable, instead of a site that is half old code and half new. When the update finishes, WordPress removes the file and the site returns. On a healthy install the window is a few seconds and nobody notices.
That is worth understanding precisely, because almost everything people believe maintenance mode protects them from, it does not.
The famous failure is one file. If an update dies partway, the PHP process times out, or somebody closes the browser tab mid update, the .maintenance file can be left behind. The site then keeps serving that screen to every visitor while the admin panics.
The fix is to delete the file. Connect over SFTP or open your host's file manager, look in the same directory as wp-config.php, and remove .maintenance. It is a hidden file, so switch on hidden files first or you will swear it is not there. The site comes back straight away.
Two things make this worse than it needs to be. The first is not knowing where your web root is, which is a surprisingly common gap and one worth closing on a calm afternoon rather than during an outage. The second is not having SFTP credentials to hand, because the person who set the site up left and nobody rotated them. If either of those is true right now, that is the actual finding of this article and it is more urgent than anything else in it. Managed WordPress hosting removes that particular scramble, but so does a password manager entry you make today.
What you do next matters more than the fix. A stuck maintenance file means an update failed, and the update that failed is still not applied. Going back to the dashboard and clicking update again without reading what broke is how a five minute outage becomes a fortnight of odd behaviour nobody can trace.
Three causes cover most stuck updates. A PHP execution timeout on a shared host, where the update simply ran out of time. Insufficient memory, which usually shows in the error log rather than on screen. Or a filesystem permission problem, where WordPress could write the maintenance file but not the plugin directory.
All three are environment problems rather than WordPress problems, which is why the same update runs cleanly somewhere else. If updates fail regularly on your site, the update process is not the thing to fix.
Most maintenance mode plugins have nothing to do with the core file. They intercept the front end and serve a branded page you control, on a schedule you choose, usually with an allowlist so logged in users or specific addresses still see the real site. That is genuinely useful for a planned change window, a redesign, or a launch you want to hold until a particular moment.
If you use one, get two details right. Return the correct status code, because a maintenance page that returns a normal success code invites search engines to index your holding screen, and one that returns a permanent error invites them to drop the page entirely. And make sure the allowlist actually works before you need it, by testing in a private window rather than assuming.
A planned window also wants a real end time on the screen. Briefly unavailable means nothing to somebody who arrived to buy something. Back at two o'clock does.
Both are front end screens. Neither one stops anything from happening to the site behind them, and that distinction is the whole point of the next section.
Here is where the feature gets misread. A maintenance screen looks like protection, so people reach for it as though it were protection. It is not a backup, not a staging environment, and not a security control.
An update that mangles the database mangles it whether or not visitors can see the front end. Maintenance mode hides the mess from customers. It does not prevent it and it does not give you a way back.
That is what a backup taken immediately before the change is for, and the word that matters is restorable. A backup you have never restored from is a hopeful file, not a safety net. Plenty of sites discover during an incident that their backups have been silently failing for months, or that they contain the files but not the database, or that restoring requires a plan nobody has written down.
If you do one thing after reading this, restore a backup to a scratch environment this month and confirm the site comes up. Not check that the backup exists. Restore it.
The screen is silent by design. If a plugin update takes out your checkout, the maintenance page will not mention it and neither will WordPress. You find out from a customer, or you find out from monitoring. One of those is considerably cheaper than the other.
Uptime monitoring alone is not enough either, because a site can return a perfectly healthy response while the thing that makes you money is broken. The checks worth having watch a transaction rather than a homepage: can the cart be reached, does the contact form submit, does the login page render. That is the difference between knowing the server is up and knowing the business is working.
Scheduled jobs, transactional email, webhooks from a payment processor, an integration pushing orders into your accounting system. None of that passes through the maintenance screen, and all of it keeps firing during your change window. This is the failure people find last, because it leaves no visible trace on the site itself.
Transactional email is the one that bites hardest, because it fails quietly and nobody notices until a customer says they never got a receipt. If your site sends mail through the server rather than a dedicated sending path, an update that touches the mail configuration can break delivery without breaking a single page. Routing transactional mail through a proper delivery path is worth doing for its own sake, and it also means one fewer thing that can silently stop.
Occasionally somebody puts a site into maintenance mode in response to a suspected compromise, on the reasoning that visitors cannot see it. The site is still running, still reachable, and still executing whatever is on it. The attacker is not browsing your homepage.
If you think you have been compromised, maintenance mode buys you a calmer screen for customers and nothing else. The response is a real one: take a forensic copy before you change anything, work out how they got in, and understand that cleaning the visible damage without closing the entry is how sites get reinfected within the week. That is a security problem and it wants a security process.
If you are making a visible change during business hours and you would rather show a deliberate page than a broken layout, use it. If you are launching a redesign and want the switch to look intentional, use it. If you are migrating and there is a window where writes would be lost, use it and say so on the screen. Those are real uses and there is nothing wrong with any of them.
What it cannot do is stand in for the process around the change: a backup you have restored from before, a staging copy where the update ran first, and something watching the site afterwards that is not a customer.
Take a backup and know it restores. Apply the update on a staging copy and click the three things that actually earn money. Apply to production. Watch for an hour, including the parts with no browser: did the overnight job run, did the receipt email arrive, did the webhook deliver.
Four steps, and the maintenance screen is optional in all of them. Most sites that get badly hurt by an update were not missing maintenance mode. They were missing step one and step four.
That process is most of what a managed maintenance plan actually is. Updates run on a staging copy first, backups are taken before the change and checked by restoring them, and monitoring watches the site afterwards rather than waiting for somebody to notice. The maintenance screen is the least interesting part of it.
It also overlaps with the neighbouring work more than people expect. Updates that keep timing out are usually a hosting problem. A site that gets slower after every update is a performance problem. A plugin that cannot be updated because a previous developer edited it directly is a development problem. Maintenance is where those surface, not where they are caused. If you are weighing managed upkeep against doing it yourself, we set the comparison out honestly on the maintenance comparison pages.
If you would rather keep doing this yourself, the honest advice is short. Test a restore this month. Put updates on a schedule you control instead of clicking when the badge appears. Watch the site for an hour afterwards, including the things that do not have a page. That gets you most of the way there and costs you nothing.