An update stopped, but what failed: downloading, unpacking, copying files, or running the new version? Keep the full message. It tells you where to start and whether another update attempt is appropriate.
First open the homepage and dashboard. If they still work, you have time to investigate. If they show a maintenance message or critical error, recover access before trying the update again.
Guide reviewed: October 8, 2026. Menu labels use English WordPress; provider-specific controls may differ.
Quick diagnosis
| Message or symptom | Check first | Do next |
|---|---|---|
| Download failed | Update service and connection | Check the package source and provider status |
| Could not create directory / copy file | Storage, ownership and write access | Give the host the exact failed path |
| Maintenance message remains | Whether the update is still active | Follow the maintenance recovery section |
| Critical error after installation | PHP log and compatibility | Investigate the updated component |
Follow the stage that failed
- Copy the complete update message into a private note.
- Open Dashboard → Updates and record the affected component and installed version.
- For a plugin, compare its details under Plugins → Installed Plugins.
- After correcting the identified cause, retry only that component and keep the update tab open.
Decision: “Download failed” and “Could not copy file” are different stages. Changing file permissions will not fix an expired download license.
A download failure points toward the update destination, network connection, or temporary storage. An extraction failure suggests checking the package and available space. A “Could not copy file” message makes file ownership and write access particularly relevant. If installation completes and a critical error follows, investigate compatibility and the affected code.
Updating one component at a time makes that distinction easier. If five plugins are selected together, it can be difficult to tell which one stopped and which ones finished. Record the installed version of the failed component before making another attempt.
For a plugin with a license-based updater, confirm that the license and download access are valid. A free repository plugin and a commercial plugin may use different update services, so one successful download does not establish that every update destination is reachable.
Give the update enough working space
Ask the host: “Is this account out of disk space or inodes, and can the PHP process write the failed path shown in the update log?” Inodes are the hosting account’s file-count allowance. A panel may show spare storage even when the file count is exhausted.
The final installed package is not the only storage involved. Downloading and unpacking need temporary space, and a hosting account can run out of its file-count allowance as well as its byte quota. Check both in the hosting panel.
Old migration archives, local backup copies, and oversized logs can consume a surprising amount of room. Review them carefully and preserve a usable backup elsewhere before removing anything. Deleting unfamiliar WordPress folders to make space can turn an update problem into missing content.
If the same file cannot be copied each time, ask your host to inspect its owner and the user running PHP. Permission numbers alone do not explain every failure. Making everything writable by everyone does not solve an ownership mismatch responsibly.
Recover an interrupted maintenance state
During an update, WordPress may temporarily display its scheduled-maintenance message. Allow an active update to finish rather than starting another one in a second tab. If the operation has clearly stopped and the message remains, the temporary .maintenance file in the WordPress root may need to be removed.
Removing that file only clears the maintenance state. It does not complete a partially installed update. Once access returns, check the versions and the failed component again. Our maintenance-mode guide explains that recovery separately.
A site that returns a critical error after leaving maintenance needs its PHP error investigated. Restore a known-good component or backup if necessary, rather than assuming the maintenance message was the entire problem.
When a clean replacement is needed
A damaged or incomplete plugin package may need to be replaced with a fresh copy from WordPress.org or its developer. Preserve custom files and check whether the product stores settings in a way that could be affected by uninstalling it. Replacing plugin files and using the Delete command are different operations.
A manual WordPress core update needs more care. Follow WordPress’s official instructions for the installed setup, keeping the existing wp-content directory and wp-config.php. Those hold site-specific files and configuration. The backup should include the database too, since some updates change more than files.
For a business site, test major version changes on staging first. Confirm the PHP version and plugin requirements before the production update. A clean copy cannot repair an incompatibility between the new code and the server.
Check the result before updating the next item
Confirm the installed version, open key pages, and test important functions such as forms or checkout. If an update requests a database step, complete that step through the expected dashboard workflow and check the result.
Keep the successful fix in your notes: a storage limit, an ownership correction, or an updated compatible package. The next failure is easier to diagnose when you know what changed. WordPress’s update documentation and file-permission guidance provide the technical reference for those repairs.
Keep a recovery record
Record the component, old and new versions, failed stage, correction and result of a public-page test. For a manual core replacement, use the official WordPress update procedure rather than replacing the entire site folder.