Clicking Update Now starts a sequence of five distinct steps, and almost every confusing error message that comes out of a WordPress update is a specific failure in a specific one of them. Once you can name the phase, the error stops being mysterious: "could not copy file" is a permissions problem in phase two, "briefly unavailable for scheduled maintenance" that never goes away is a leftover flag file from phase one, and a site that looks completely unchanged afterwards is usually phase five, which WordPress does not do for you.
This article is the mechanism, not the fix. The fixes for the individual errors have their own pages. What this gives you is the map.
Version and verification. Written against WordPress 7.0.2, released 2026-07-17, current stable. WordPress 7.0 shipped 2026-05-20 and 7.1 is scheduled for 2026-08-19. The process below is documented in WordPress's own Updating WordPress documentation and has been stable across many releases. Last verified 2026-07-30.
The five phases, in order
- WordPress raises a flag that puts the site into maintenance mode.
- It downloads and replaces files, which is the step that needs write permission.
- It upgrades the database, which is a separate event and sometimes happens later than you think.
- It lowers the flag and maintenance mode ends.
- You clear the caches and check the site, which WordPress does not do.
Only phases one to four are WordPress's. Phase five is the one that gets skipped, and it accounts for a surprising share of "the update did not work" reports.
Phase 1: the flag file, and why your site says "briefly unavailable"
Before WordPress extracts a single new file, it writes a file called .maintenance into your WordPress directory. That file is a flag. Its presence tells WordPress to stop serving the normal site and to show the maintenance message instead, and it carries the information needed to display that message.
While the flag is up, visitors get a short "briefly unavailable for scheduled maintenance" page rather than your site. That page returns an HTTP 503 status with a Retry-After header, which is the correct behavior rather than a problem: 503 with Retry-After tells search engines the condition is temporary and to come back, instead of implying the page is gone for good. A plain error page would not communicate that.
The reason the flag exists at all is consistency. During phases two and three, the files on disk and the structure of the database are briefly out of step with each other. If visitors and logged-in users kept interacting with the site during that window, they would be running new code against an old database or the reverse, which is how data gets corrupted. Maintenance mode is the door being held shut for a few seconds.
On most sites this phase lasts a handful of seconds. If it lasts longer than a minute, something in phase two stalled and the flag was never removed, which produces the single most common panic in this whole process.
Phase 2: replacing the files, and the part that needs permission
WordPress downloads the release package, unpacks it, and replaces core files. This is the phase where the interesting failures live, and they all come from the same place: whether WordPress is allowed to write to your own filesystem.
WordPress works this out by looking at who owns the files. If the WordPress files are owned by the same user the web server runs as, and new files created by WordPress would also be owned by that user, WordPress writes the files itself and you never see a prompt. If the ownership does not line up, WordPress will not force it. Instead it shows you a dialog asking for connection credentials, typically the FTP account that originally uploaded the files.
That is why some sites update with one click and others ask for FTP details every single time. It is not a bug and it is not something wrong with your site. It is a consequence of how the install was set up and how your host configures ownership, and on some shared hosting it is deliberate, because files owned by the web server user are a security risk on those platforms.
The failures in this phase:
- A request for FTP or SSH credentials means WordPress decided it cannot write as its own user.
- "Update failed: could not copy file" means a write was attempted and refused, usually a permissions problem, occasionally a disk-space problem.
- A partial replacement, where some files are new and some are old, which is the worst outcome and the reason the maintenance flag exists.
Phase 3: the database, which is a separate event
This is the phase most people do not know exists, and understanding it explains a great deal.
Files and database are updated at two different moments. Replacing the files does not change the database. When a WordPress release needs the database structure changed, WordPress detects that the code and the database no longer match, and runs an upgrade routine. If it happens automatically, you never see it. If it does not, WordPress will send you to a page at /wp-admin/upgrade.php with a link and an instruction to run it, which WordPress's own documentation says to do as soon as possible after the files are in place.
Plugins do the same thing on their own schedule. A major plugin version often migrates its own stored data the first time it is activated after the update.
Two consequences follow, and they are the two most useful things in this article:
- A database upgrade can be triggered by you, later, just by loading the admin. If you replaced files manually and then visited
/wp-admin, that visit is what ran the upgrade. - Putting older files back does not undo a database upgrade. This is the entire risk profile of a rollback in one sentence, and it is why rolling back a plugin the same afternoon is usually fine while rolling back core weeks later is not.
Phase 4: the flag file comes off
When the files are all in place and the update has finished, WordPress deletes the .maintenance file, the maintenance message disappears immediately, and the site serves normally again.
If phase two failed partway through, this deletion never happens. The flag stays up and your site stays unavailable, indefinitely, even though nothing is actively happening. That is what a site stuck in maintenance mode is: not an update still running, but an update that stopped and left the door shut behind it.
WordPress's own documentation names the remedy directly: if you see a failed-update notice, delete the .maintenance file from your WordPress directory. That is a temporary flag file, not part of WordPress, and removing it is WordPress's own documented instruction. It is also the only file this article will ever tell you to delete, and nothing here asks you to edit a core file, which you should not do under any circumstances.
Phase 5: the part WordPress does not do for you
Two things remain after WordPress has finished, and it does neither.
Clearing the cache. If you run a caching plugin, a host page cache, or a CDN, they are still serving the pages they cached before the update. WordPress's own instructions include clearing the cache as an explicit step, because otherwise visitors, including you, keep seeing the old version until the cache expires on its own. A successful update behind a stale cache looks exactly like an update that did nothing.
Reactivating anything you deactivated. If you deactivated plugins before a manual update, as WordPress's manual-update instructions tell you to, they are still deactivated. Turning them back on is on you, and doing it one at a time rather than all at once is how you find out which one has a problem.
There is a third, if login behaves strangely afterwards: clearing your browser cookies is the documented first step, because an update can change how session data is handled.
What is never touched
Worth stating explicitly, because the fear that an update will delete a site is common and it is a fear of something that does not happen.
| Not replaced by a WordPress update | Why it matters |
|---|---|
wp-config.php |
Holds your database credentials and site constants. WordPress's own documentation confirms it is safe. |
The wp-content directory |
Your themes, your plugins and your uploads live here. A core update does not delete it, and WordPress's manual-update instructions specifically warn against deleting it yourself. |
| Your uploads | Every image and file you have ever added. |
| Your posts, pages, comments, users and settings | These are in the database, and a core update changes the database's structure rather than its contents. |
What is replaced: the wp-admin and wp-includes directories in full, and the loose files in the WordPress root such as index.php and wp-login.php. Which leads to the one genuine content risk in a core update, and it is not the one people worry about: if you edited a core file, that edit is gone. WordPress's documentation states this as a warning at the top of its update instructions. It is also the reason nobody should ever edit a core file, and the reason theme customizations belong in a child theme rather than in the theme's own files, which a theme update overwrites for the same reason.
The error-to-phase map
The payload of this article, in one table.
| What you see | Phase | What it actually means |
|---|---|---|
| "Briefly unavailable for scheduled maintenance", not clearing | 1 and 2 | The update stopped partway and left the .maintenance flag up. |
| A prompt for FTP or SSH credentials | 2 | File ownership means WordPress cannot write as its own user. |
| "Update failed: could not copy file" | 2 | A write was refused. Permissions, or occasionally disk space. |
| A "failed update" notice after you retried | 2 | The leftover .maintenance file is still there. |
Being sent to /wp-admin/upgrade.php |
3 | Normal. The database needs its structure updated. Run it. |
| "There has been a critical error on this website" | After 4 | The update finished and something now running is fatally broken, most often a plugin. |
| One feature stopped working, everything else is fine | After 4 | A single plugin's incompatibility. |
| The site looks exactly as it did before | 5 | The cache. Almost always the cache. |
Two of those have their own dedicated walkthroughs already: the critical error after an update, which covers recovery mode for both the locked-out and partially-broken cases, and a plugin that stopped working after the update, which covers the fix-in-place options before it gets anywhere near a rollback.
Why a minor update happens without you and a major one does not
Since WordPress 3.7, most sites apply minor and security releases automatically in the background without anyone clicking anything. Major feature releases still wait for you to click Update Now.
The distinction is deliberate and it maps onto phase three. Minor releases are almost always fixes, and they rarely change the database structure, so applying them unattended is low risk and leaving them unapplied is the greater danger. Major releases can change how things work, can move a floor such as a minimum PHP version, and are far more likely to expose a plugin incompatibility. Those need a human who has decided when, and who is at their desk afterwards.
That is why 7.0.1 and 7.0.2 likely installed themselves on your site and 7.1, on 2026-08-19, will sit there waiting.
Plugin and theme auto-updates are a separate system, opt-in per item on the Plugins and Appearance screens, and they run twice a day by default. That default is worth knowing, because it is why a plugin you rolled back can reinstall itself overnight.
What this changes about how you update
Knowing the phases changes three practical things.
You stop panicking about maintenance mode, because you know it is a flag file and you know that a stuck one is an ordinary condition with a documented remedy rather than a lost site.
You check the cache before you conclude anything. It is the cheapest check available and it explains a disproportionate number of apparent failures.
You understand why a backup is the real safety net and a rollback is not. Files and database move separately, a rollback returns only one of them, and a restore returns both consistently. That is the reasoning behind the first step of the twenty-minute pre-update checklist, which is to confirm you can restore a backup rather than merely that you have one. For the wider view of what the 7.x releases changed and what tends to break on them, the site owner's guide to WordPress 7 is the overview.
