The Update Failed and the Site Is Half-Updated
An update that stops partway leaves the site in an undefined state: some files new, some old, possibly a lock file still in place. The recovery is straightforward, but it has to be done in the right order.
The short version
- Delete .maintenance first so the site comes back.
- Then determine what actually completed.
- Finish the update properly rather than leaving it partial.
- Then find out why it stalled, or it recurs.
1. End maintenance mode
rm .maintenance # in the web root, hidden file
The site returns immediately. This only ends the maintenance message — it does not finish the update.
2. Find out what state you are in
# is core complete and unmodified?
wp core verify-checksums
# what version does WordPress think it is?
wp core version
# are plugin files intact?
wp plugin verify-checksums --all
# anything still pending?
wp plugin list --update=available
These four commands tell you whether the problem is core, a plugin, or both.
3. Finish a core update
wp core download --force
wp core update-db
The first replaces every core file with a clean copy of the current version, leaving wp-config.php and wp-content alone. The second runs any pending database migrations, which is the step people forget and which causes odd behaviour afterwards.
4. Finish a plugin update
# reinstall at the current version
wp plugin install the-plugin --force
# or roll back to the version that worked
wp plugin install the-plugin --version=2.4.1 --force
If the plugin folder is half-written, deleting it and reinstalling is safer than trying to repair it. Settings live in the database and survive.
5. Check for leftover temporary files
ls -la wp-content/upgrade/
ls -la wp-content/upgrade-temp-backup/ 2>/dev/null
WordPress stages updates in wp-content/upgrade. A failed update leaves folders there. Once the site is working and verified, these can be removed — they serve no purpose and consume inodes.
Why updates stall
| Cause | Symptom | Fix |
|---|---|---|
| PHP timeout | Large plugin, slow server | Raise max_execution_time, or update via WP-CLI |
| Memory exhausted | Several updates at once | Raise memory, update individually |
| Disk full | Fails silently partway | Free space, check inodes |
| Permissions | Asks for FTP credentials | Fix file ownership |
| Connection dropped | You closed the tab | Use WP-CLI, which does not depend on the browser |
| Host-level kill | Process exceeded a resource limit | Update via WP-CLI, or ask the host |
Updating reliably from now on
- Use WP-CLI where you can. It does not run under the web server’s execution timeout and does not depend on a browser tab staying open.
- Update in small batches so a failure is easy to locate.
- Take a backup immediately before each batch.
- Do it on staging first on anything that matters.
- Never update from a flaky connection.
Watch out
If the site is working but behaving strangely after a partial update, run wp core update-db. A core update that completed its files but not its database migration produces exactly that — everything loads, small things misbehave.
Common questions
Can I lose content?
Very unlikely. Updates replace files, not database content. The database migration step is the only part that touches data, and it is designed to be safe.
Should I restore a backup instead?
If you have a clean one from minutes before, that is the fastest route. Otherwise finishing the update is usually quicker than a full restore.
The site works but the dashboard still says update required
Run wp core update-db, then clear every cache.
Sumit
Writes everything on TechMozz.