WordPress creates .maintenance while replacing files and normally removes it on completion. If the process stops, deleting the file restores requests but does not prove core files or the database upgrade finished.
Preserve logs and inspect the update state before running it again.
Confirm no update is still running
Record the outage time and inspect hosting processes, WordPress update logs and the .maintenance timestamp. Another administrator or deployment may still be extracting files.
Do not delete the marker while a legitimate process writes core files. Concurrent updates can leave a mixed installation.
Check public and administrator responses and free disk/inodes.
Inspect automatic-update evidence
WordPress can send a technical update email and record filesystem/download errors. Check the site administrator mailbox, wp-content/upgrade, hosting event logs and any management platform that initiated the update.
Distinguish a scheduled background update from a manual browser request. If a deployment service also manages core, disable overlapping ownership before recovery so it does not immediately reapply another version.
Back up the interrupted state
Create a recoverable files/database backup or hosting snapshot. Keep the last pre-update backup separately.
The interrupted copy helps identify partial files and database changes. Do not overwrite it with a new full restore.
Ensure backup creation itself will not consume the remaining disk.
Remove maintenance mode deliberately
When no update process remains, rename or remove only .maintenance from the WordPress root using authorised file access.
.maintenance
.maintenance.interrupted-backup
Renaming preserves evidence. Reload once and read the resulting PHP/HTTP error; it may reveal missing core files.
Custom maintenance plugins are separate and should not be removed by this step.
Check why the update stopped
Inspect PHP/web logs for timeout, memory, permission, download or extraction errors. Check hosting resource limits and outbound connectivity to WordPress.org.
Wrong filesystem ownership can allow reads but block replacements. Follow cPanel/Plesk/host guidance; do not use recursive 777.
If auto-updates use FTP credentials, verify the configured method and secure credential storage.
Verify core files
Use WP-CLI checksums for the installed WordPress version:
wp core verify-checksums
wp core version
Run in the correct document root. Custom wp-content, uploads and wp-config.php are not replaced by a standard core reinstall.
Download core only from official sources and preserve the intended language/version.
Reinstall the exact core version
Replace incomplete core files through WP-CLI or a trusted manual package, excluding wp-content and configuration. Back up first and clear OPcache afterward.
Do not delete the entire WordPress root or uploads. Confirm filesystem ownership before retrying.
If the target release caused plugin incompatibility, restore service on a supported compatible version while preparing the forward fix.
Verify language and bundled files
Core translations and bundled themes may update in separate steps. Check Dashboard > Updates after core is consistent and install only the language packs intended for the site.
Do not treat a translation download failure as core corruption, but confirm the administrator does not contain mixed strings from incomplete packages. For multisite, verify network administration and each site’s language choice.
Check that default bundled themes retained for emergency fallback are complete and trusted.
Complete the database upgrade
After files are consistent, WordPress may request a database upgrade. Run it once through the administrator or:
wp core update-db
Take a database backup and read output. Do not repeatedly run upgrades while PHP errors persist.
Multisite needs network-aware commands and validation across sites.
Verify and prevent recurrence
Test public templates, administrator, editor, media, cron and REST API. Confirm .maintenance does not reappear and checksum verification passes.
Monitor PHP/errors after reopening. Recurring care should pre-check disk, permissions and compatibility, then stage high-risk core releases; removing the maintenance file is only the beginning of recovery.