Initial assessment without passwords Quote before intervention One accountable specialist from start to finish

Plugins Themes Updates

WordPress Core Update Stops Halfway and Leaves Maintenance Mode

Recover a WordPress core update stuck in maintenance mode by checking active processes, disk, permissions, checksums and database upgrade.

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.

BEFORE YOU SEND THE REQUEST

Frequently asked questions.

Do you ask for passwords in the form?+

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?+

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?+

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?+

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

Assess my incident