Briefly unavailable for scheduled maintenance
WordPress writes a .maintenance file before an update and removes it after. The update did not finish, so the file is still there.
Briefly unavailable for scheduled maintenance. Check back in a minute.
Delete the .maintenance file in the web root and the site returns immediately. That is the whole fix - but an update that died halfway may have left files partly replaced, so verify core afterwards.
What causes it, most likely first.
Work down the list. Each check is written to rule its row in or out before you change anything, because the fixes below it are different and a guess costs more than a command.
| Cause | How to check | Fix |
|---|---|---|
| An update timed out mid-run | The file's timestamp matches when you started the update, and the update never reported success. | Delete the file, then re-run the update somewhere without a timeout over it. |
| The browser tab was closed during an update | You navigated away or the connection dropped while the progress screen was showing. | Delete the file and re-run. Nothing is corrupted by this on its own - the flag simply outlived the process that set it. |
| Bulk updates ran out of memory | Several plugins were updating at once and the error log shows an out-of-memory fatal at that time. | Delete the file and update in smaller batches, or from the command line. |
| A half-replaced core | The site returns after deleting the file but behaves oddly - missing admin screens, or version numbers that disagree. | Verify core checksums and re-install the same version. Deleting the flag does not finish an interrupted copy. |
| The file cannot be deleted | The web user does not own it, so the update could not remove it either. | Fix ownership in the web root. Mixed ownership is why this error becomes permanent rather than momentary. |
Fixing it, step by step.
Commands assume WP-CLI and shell access. Where you have neither, each step says what it is doing so it can be done from the dashboard or over SFTP instead.
Confirm the file is there
It is a dotfile in the web root, so it will not show in an ordinary listing.
ls -la .maintenance
Delete it
The site is back the moment it is gone. No restart, no cache flush.
rm .maintenance
Check that core is intact
An interrupted update can leave some files replaced and others not.
wp core verify-checksums
Finish the update that failed
From the command line, where a browser tab cannot end it early.
wp core update && wp plugin update --all
Make sure the files are owned by the web user
If they are not, the next update will fail the same way.
ls -la wp-content | head -n 5
What the platform takes off the list.
Updates run through the platform rather than through a browser tab, so a closed window cannot leave the flag behind, and the admin context has execution limits sized for the work instead of the thirty seconds a web request gets. Ownership across the web root is set at deploy and stays consistent, which removes the version of this where the file cannot be deleted at all.
Questions, answered.
Is it safe to just delete the file?
I cannot see the file over SFTP.
It came back after I deleted it.
Will my visitors have seen this?
If that was not it.
These fail in ways that look similar from the browser.