What Maintenance Mode Really Does
Maintenance mode is a holding page. There is nothing more to the feature than that.
During a core, plugin, or theme update, WordPress writes a small file called .maintenance into your web root. While it exists, logged out visitors see a plain message that the site is briefly unavailable, so they never land on a site that is half old code and half new. When the update ends, WordPress deletes the file. On a healthy install that takes a few seconds and nobody notices.
Most of what people assume it protects them from, it does not touch. This post sorts out which is which, and starts with the case that brings most readers here: a site stuck on that message.
Why a Site Gets Stuck in It
One leftover file does it. An update dies halfway, the PHP process times out, or someone closes the browser tab mid-update, and .maintenance stays behind. Every visitor keeps getting the holding screen while the admin stares at it.
Delete the file. Connect by SFTP or open your host's file manager, go to the folder that holds wp-config.php, and remove .maintenance. It starts with a dot, so it is hidden until you switch on hidden files, and plenty of people conclude it is not there. Once it is gone, the site comes back immediately.
The scramble usually has one of two causes. Either nobody knows where the web root is, or the SFTP login left with whoever built the site and was never replaced. Fix both on a quiet afternoon, not during an outage. A password manager entry takes five minutes, and managed WordPress hosting removes the hunt for the folder altogether.
If the file is gone and the site still shows the message, clear any page cache and look in a private window before assuming something else is wrong. A cached copy of the holding page is common.
The file is the easy part. A stuck file means an update failed, and that update is still not applied. If you go back to the dashboard and click Update again without finding out what broke, a five minute outage turns into two weeks of odd behavior that nobody can trace.
What Usually Caused the Failed Update
Three causes cover most of them. On shared hosting, PHP's execution time ran out before the update finished. Memory ran short, which tends to show up in the error log rather than on screen. Or file permissions let WordPress write the .maintenance file but not the plugin directory, so it could start the job and not complete it.
All three belong to the environment, not to WordPress, which is why the same update goes through cleanly on another host. If updates fail on your site more than once, stop retrying them and look at the server.
Plugin Maintenance Mode Is a Different Animal
Maintenance plugins never touch the core file. They intercept the front end and serve a page you design, on your schedule, usually with an allowlist so logged in users or certain addresses still see the real site. For a planned change window, a redesign, or a launch you want to hold until a set time, that is the right tool.
Two details matter if you use one. First, the status code. A holding page that answers 200 invites search engines to index it as your homepage. The standard answer is 503 with a Retry-After header, which tells crawlers the outage is temporary. Second, test the allowlist in a private window before you need it. Assuming it works is how people lock themselves out of their own launch.
Plugin pages also differ in what they let through. Some block the login page and the REST API along with the front end, so check that your own team can still work before you announce the window.
Put a real end time on the screen as well. "Briefly unavailable" means nothing to someone who came to buy something. "Back at 2 PM" does.
Both Kinds Are Front-End Screens
Neither the core file nor a plugin stops anything from happening to the site behind the screen. That gap is the subject of the second half.
What It Was Never Going to Catch
A maintenance screen looks like protection, so people treat it as protection. It is not a backup, not a staging site, and not a security control.
Your Data Is Not Protected
If an update mangles the database, it mangles it whether visitors can see the front end or not. The holding page hides the mess from customers. It does not prevent the damage, and it gives you no way back.
A backup taken right before the change does that job, provided it is restorable. A backup you have never restored from is a hopeful file. Sites find out in the middle of an incident that their backups have been failing for months, or hold the files without the database, or need a restore procedure nobody wrote down.
Restore one to a scratch environment this month and confirm the site comes up. Checking that the backup exists does not count.
It Will Not Tell You What Broke
The screen says nothing by design. Suppose a plugin update takes out your checkout. Neither the holding page nor WordPress will mention it. You hear about it from a customer or from monitoring, and one of those costs a lot less.
Plain uptime checks fall short too, since a site can answer with a healthy response while the part that earns money is broken. Better checks follow a transaction instead of a homepage: can the cart load, does the contact form submit, does the login page render. Those tell you whether the business is working, and an uptime ping only tells you the server is.
Anything Without a Browser Keeps Running
Scheduled jobs, transactional email, webhooks from a payment processor, an integration pushing orders into your accounting system: none of it passes through the maintenance screen, and all of it keeps firing during your change window. People find this one last, because it leaves no trace on the site.
Email hurts most. It fails quietly, and the first sign is a customer asking where their receipt went. If your site sends mail through the server itself, 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 anyway, and it takes one more silent failure off the list.
It Is Not a Security Measure
Now and then someone flips on maintenance mode after spotting a possible compromise, reasoning that visitors can no longer see the site. The site is still running, still reachable, and still executing whatever is on it. An attacker is not browsing your homepage.
So the screen buys customers a calmer view and does nothing else. A real response comes first: take a forensic copy before you change anything, work out how they got in, and remember that cleaning up the visible damage without closing the entry point is how sites get reinfected inside a week. That is a security problem and needs a security process.
Where It Is the Right Tool
Use it when you are making a visible change during business hours and want a deliberate page in place of a broken layout. Use it when a redesign launch should look intentional. Use it during a migration, when writes in a certain window would be lost, and say so on the screen. All of those are fine.
What it cannot do is replace the process around the change: a backup you have restored from, a staging copy where the update ran first, and something watching the site afterward that is not a customer.
A Four-Step Change Process You Can Run Yourself
Take a backup and know it restores. Run the update on a staging copy, then click through the three things that earn money. Apply it 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.
The maintenance screen is optional in all four. Sites that get badly hurt by an update were rarely missing maintenance mode. They were missing step one and step four.
What the Process Looks Like When Someone Owns It
That process is most of what a managed maintenance plan is. Updates run on a staging copy first, backups are taken before the change and checked by restoring them, and monitoring watches the site afterward so a customer does not have to. The holding screen is the least interesting piece.
The neighboring work overlaps more than people expect. Updates that keep timing out are usually a hosting problem. A site that slows down after every update is a performance problem. Maintenance is where those show up, not where they start. To weigh managed upkeep against doing it yourself, the maintenance comparison pages set it out honestly.
If you would rather keep doing this yourself, the advice is short. Test a restore this month. Schedule updates for a time you pick instead of clicking when the badge appears. Watch the site for an hour afterward, including the things that have no page. That gets you most of the way, and it costs nothing.
