WordPress update failed with 500

Symptoms

You pressed Update on a plugin, theme, or WordPress core and the page died with a blank white area, an HTTP 500, or the error "Update failed: The package could not be installed." The site may still work or may be down. Treat the situation as a half-finished write, not a choice: a failed update can leave files in a mixed state, with new code running against old data, until you decide whether to complete it or roll it back.

What a 500 during update means

A 500 after a failed update is usually one of:

• An incomplete file copy. The update killed a zip while it was mid-write. Permissions then block the remaining writes.
• A PHP fatal at the exact moment a newer function runs against older files. This is the same family as the 500 internal server error.
• A resource wall. Updates unpack to disk and process files, so the memory or execution limits of PHP show up in a way a normal page load never hits.
• A database change that already applied (a migration in a plugin) while the file half-updated, so the two versions disagree.

The safe fix order

1. Stop touching anything. The first priority is never to run the update again right away, or the site half-writes a second time.
2. Roll back the broken piece. If the update hit a plugin or core, reinstall the previous known-good version. WP-CLI can do this without admin:

- Reinstall core pinned to the exact version that was live. A plain wp core download fetches the latest core, not the previous one, so pin the version explicitly:

   wp core update --version=6.4.3 --force

Replace 6.4.3 with the version number that was running before the failed update.

- Delete an upgraded plugin and reinstall its prior version from a zip you keep.

In either case you first confirm the error is really event-specific: a temporary file lock that a restart solved is cheap.

1. Verify file permissions. The update needs write access on the impacted paths. The classic policy:

- Files: 644, directories: 755.

- wp-content and wp-content/uploads recursively writable by the web server user (so updates, media, and generated files work), but not world-writable.

If the web user and the shell user differ, chown the web tree to the web user, then set the mode; a wrongly-owned file makes one-click updates fail with 500 right after extraction.

1. Free disk and check space. Updates unpack sizable files. On a small disk the extraction dies mid-write and reports 500:

df -h /var/www

Keep at least a few hundred MB free above the site itself, or the next update aborts. Remove object cache, old backups, and generated logs inside wp-content first.

1. Check the PHP version those new files need. Core releases keep a floor across recent versions, but a plugin jumping two major versions may refuse an older patch. Read the host's PHP version and compare. A plugin that worked on PHP 8.1 can 500 on 7.4 even after a clean install.
2. Deactivate plugins before a manual core update. A plugin can be the exact thing that 500s a core update, so a manual core update should run with the plugin layer out of the way. WP-CLI keeps a record of what was active, so one command deactivates everything and another restores them:

wp plugin deactivate --all
wp core update
wp plugin activate --all

If your theme is also in the suspect list, swap to a default theme in the same pass. This is the same isolation trick covered by the plugin isolation flow.

1. Retry the update manually via WP-CLI. With plugins deactivated, if the site is up, running updates from the shell avoids the timeouts and half-writes of the browser queue and prints the exact failing line:

wp plugin update --all
wp core update
wp plugin status

Then run the site in a private window. A 500 that vanishes means the admin queue had the problem; a 500 that stays means a code-level issue still, in which case roll back the newer version. Note WP-CLI is invoked as wp on most hosts; some panels expose it as wp-cli.

Verification table

Prevention

• Use staging: every core, theme, and plugin update goes through a staging copy, plus a backup of the database and files beforehand.
• Run the browser queue in one window and only schedule, do not leave several plugins updating at once.
• Keep the exact web-server user permissions recorded in the deploy doc, so a clean server reproduces them in one file.