If WordPress keeps showing its scheduled-maintenance message after an update, first establish whether the update is still running. Removing the message and completing the update are different jobs. A normal-looking homepage does not tell you whether the intended plugin or core files were installed successfully.
Identify which maintenance screen you are seeing
The built-in update notice, a branded coming-soon page, and a hosting-provider error page need different responses. Save a screenshot and the time it started. Check the admin dashboard and hosting panel for an active update or deployment. Do not start a second updater while another is working.
| Observation | Next check |
|---|---|
| Update still shows progress | Confirm progress with the host before touching its files. |
| Branded maintenance page | Check the maintenance plugin or hosting setting. |
| Update stopped but WordPress notice remains | Check for a stale maintenance flag. |
| Only some visitors see the message | Compare cached and uncached responses. |
Remove a stale flag only after the update has stopped
WordPress uses a file named .maintenance in the installation directory during updates. A failed update can leave it behind. Once you have confirmed no update is running, use your host's file manager or SFTP to locate the correct installation, enable hidden-file display, and remove that specific stale file. Do not delete wp-admin, wp-includes, or a similarly named plugin directory. The official WordPress update guide explains this recovery step.
If there are multiple installations under the hosting account, match the directory to the affected domain before changing anything. Ask the host to identify it if uncertain. Preserve a current backup; the existence of a scheduled backup is not proof that a restoration will work.
Check the update outcome
Reopen the dashboard and compare the installed version with the intended version. Look for an update-failure message and inspect hosting logs around the failure time. If the site now shows a fatal error, follow the critical-error investigation rather than repeatedly deleting the maintenance file.
A useful incident note separates observations: the maintenance screen disappeared, the dashboard loaded, the plugin version changed, and the checkout test passed. Each is evidence for a different part of recovery. Keep failures in the note too, so the next person does not repeat a risky step.
Before the next update
Ask your host to review available disk space, file ownership, and resource-limit errors if updates repeatedly stop. Do not solve write errors by making every directory publicly writable. Test the next update on staging, schedule a low-impact window, and keep a record of which component changed.
If you need help, include the exact notice, affected domain, component being updated, and whether an updater is still active. A free human review can establish the next step and any cost before paid work begins.