WordPress creates a .maintenance marker during updates. An interrupted update can leave the marker behind. A maintenance page created by a plugin or hosting service is a separate mechanism.
Check whether the update is still running
Do not remove the marker while an update is active. Check the initiating browser tab and the hosting update panel. If you cannot confirm whether work is still running, ask the host to verify the process.
Record which component was being updated and when. A remaining maintenance marker does not prove that the underlying update completed successfully.
Prepare file access and a copy
Use the host's file manager or SFTP with access to the correct WordPress installation. Enable showing hidden files. Identify the installation root containing wp-admin, wp-includes and wp-config.php; a site can live in a subdirectory.
Keep a current backup or have the host preserve the broken state before recovery. Download a copy of the marker before removing it. Do not delete other dotfiles, directories or unfamiliar maintenance files.
Remove only the confirmed stale marker
- Confirm with the host or update tool that the update has stopped.
- Locate the exact .maintenance file in this installation's root.
- Preserve a copy, then remove that file only.
- Reload the public site and admin.
- If a maintenance page remains, investigate a plugin, host setting or cached response instead of deleting more files.
If file access or the installation path is unfamiliar, ask the host to perform this operation. The purpose is to remove a stale flag, not rebuild WordPress manually.
Check the interrupted update
Open Dashboard → Updates and inspect installed versions and any failure message. Test the affected plugin or theme and the public site. Ask the host to check disk space, permissions and server logs if another attempt fails.
An incomplete file replacement can still cause a fatal error after the marker is removed. Use the official update recovery process or a verified backup. Do not combine files from several unrelated versions.
For a production shop, preserve orders and submissions before restoring an older database. A full restore can remove data created after the backup.
Reduce repeat failures
Retry only after the underlying problem is understood and a fresh backup is available. Keep one update operation active at a time and monitor its completion. Check the host's available storage and update permissions rather than repeatedly refreshing the same operation.
Finish by testing login, a public post, navigation and important forms. Record the version and recovery action for the site's maintenance log.
Sources & verification
Sources checked September 29, 2026. Documented behavior is distinct from hands-on testing.