Briefly Unavailable for Scheduled Maintenance: Delete One File

If your WordPress site says it is briefly unavailable for scheduled maintenance and has been saying it for more than a minute, an update failed partway through and left behind a file called .maintenance in your site root. Delete it and the site returns.

That is the whole fix, and it takes about thirty seconds. But deleting the file only clears the symptom — an update was interrupted, and depending on where it stopped you may have a half-updated plugin or a partially replaced core. This post covers the fix and then the part most articles skip: finding out what went wrong and whether anything is left broken.

Table of contents

• What the message actually is
• Deleting the file
• Finding out what interrupted the update
• Checking whether anything is left broken
• Preventing the recurrence
• How this fits the rest of the stack
• FAQ

What the message actually is

When WordPress starts an update it writes a file named .maintenance into the site root. That file contains a PHP timestamp of when maintenance began. Every page load checks for it, and if it is present and recent, the site serves the maintenance message instead of the page.

On a successful update the file is deleted at the end and the whole thing lasts a few seconds. Most users never see the message at all.

If the update dies before that cleanup — PHP timeout, memory exhaustion, a lost connection, a fatal error in the update code — the file stays. And because it stays, the site keeps serving maintenance mode indefinitely.

There is a subtlety worth knowing: WordPress ignores the file if the timestamp inside is more than ten minutes old. So on some installations the site recovers by itself after ten minutes. When it does not, it is usually because something keeps rewriting the file — an update process retrying on every page load — or because a caching layer is serving a stored copy of the maintenance page.

Deleting the file

The file is named .maintenance, with a leading dot, and it lives in the WordPress root — the same directory as wp-config.php, wp-admin and wp-content.

The leading dot makes it a hidden file, which is the main obstacle. Depending on your access:

• Dashboard file manager. Look for a show hidden files option and enable it, then delete .maintenance. This is the fastest route when your host provides one.
• SFTP or FTP. Enable hidden files in your client — in FileZilla it is Server then Force showing hidden files — then delete it.
• SSH. rm /path/to/site/.maintenance. Confirm you are in the right directory first with ls -la, which shows hidden files.
• WP-CLI. wp maintenance-mode deactivate handles it if the CLI is available.

Reload the site. It should come straight back. If it does not, clear any caching layer — a page cache or CDN may be serving a stored copy of the maintenance page long after the file is gone.

If you cannot find the file at all, check you are looking in the actual WordPress root rather than a parent directory, and make sure hidden files really are being shown. It is a very small file and it is easy to scroll past.

Finding out what interrupted the update

Deleting the file gets the site back. It does not tell you why the update stopped, and if the cause is still present the next update will do the same thing.

The usual causes, roughly in order:

1. PHP execution timeout. Updating several plugins at once takes longer than max_execution_time allows and the process is killed. The most common cause by a distance, and the reason updating everything at once is a bad habit.
2. Memory exhaustion. memory_limit reached while unpacking or copying files. Look for a fatal allowed memory size error in the PHP error log.
3. Browser closed or connection lost. Updates run in the request, so navigating away or losing connectivity mid-update can leave it incomplete.
4. Disk full. Updates need temporary space to download and extract. A full disk fails in confusing ways across the whole site, not only updates.
5. Filesystem permissions. WordPress cannot write to the directory it is updating, and fails partway.
6. A fatal error in the plugin being updated, or in another plugin triggered during the process.

Check the PHP error log for the timestamp of the failure. It will usually name the cause directly, and this is the step that turns a recurring problem into a fixed one.

Checking whether anything is left broken

An interrupted update may have left files half-replaced. Verify rather than assume, because a partially updated plugin can fail in subtle ways rather than obviously.

1. Check the site loads, front end and admin. If the admin is broken too, you have a bigger problem than the maintenance file.
2. Check versions. In the dashboard, compare what is installed against what should be. Anything that reports an unexpected version was caught mid-update.
3. Re-run the update for anything that looks wrong — one item at a time, not in a batch. Reinstalling over a partial update is normal and safe.
4. Reinstall core if needed. Updates then WordPress then Reinstall Now replaces the core files without touching content, and is the clean fix if core was mid-update.
5. Walk the critical paths. Whatever the site is actually for — checkout, contact form, login, media upload — click through it. Automated checks miss things that only fail in use.
6. Check for a database migration. Some plugins run one on update. If a plugin was interrupted between file replacement and migration, its own admin screen usually offers to complete the update.

If the site is badly broken and you have a backup from before the update, restoring is often faster and more reliable than repairing a partially-updated installation piece by piece.

Preventing the recurrence

This failure is entirely preventable and the preventions are small.

• Update one thing at a time. Selecting all plugins and updating in one batch is the single biggest contributor to timeouts. One at a time takes longer for you and much less time per request.
• Raise the limits if you control them. max_execution_time and memory_limit set generously enough that an update has room. On shared hosting you may not be able to; on managed hosting this is typically handled.
• Back up before updating, and confirm the backup finished. This is what makes a bad update an inconvenience rather than an incident.
• Do not close the tab. Updates run in the request; let them finish.
• Keep disk space free. Monitor it, because a full disk produces a variety of unrelated-looking failures.
• Update regularly. A site updated weekly applies small increments. A site updated once a year applies a large batch, which is exactly the situation that times out.

If this keeps happening despite all of that, the underlying issue is usually that the hosting environment is too constrained for the site running on it. A site that cannot complete its own updates within the available execution time and memory is a site that is going to have other problems too.

How this fits the rest of the stack

Most of the friction here is access — needing an FTP client to delete a hidden file, or phpMyAdmin to check a table, while the site is down. The RunxBuild hosting calculator covers what running the site costs alongside the rest of the stack. RunxBuild managed WordPress puts a file manager and a database browser in the dashboard: browse, edit, upload, unzip and delete files including hidden ones, and inspect tables, run SQL and export or import — so clearing a stuck .maintenance file is a click rather than a hunt for credentials.

Useful related references:

• Maintenance Page: The Version That Actually Helps Users Come Back, Not a 503 Wall
• HTTP 503: What Is Actually Broken When the Service Is Unavailable
• Persistent Crontab: Making Scheduled Jobs Survive Reboots and Containers
• Services on RunxBuild

FAQ

How do I fix briefly unavailable for scheduled maintenance in WordPress?

Delete the file named .maintenance from your WordPress root — the directory containing wp-config.php. It is hidden because of the leading dot, so enable hidden files in your file manager or FTP client first. The site returns immediately, though you may need to clear a page cache or CDN.

Where is the .maintenance file?

In the WordPress root directory, alongside wp-config.php, wp-admin and wp-content. The leading dot makes it hidden, so file managers and FTP clients will not show it until you enable hidden files. Over SSH, ls -la lists it.

Why did my WordPress update get stuck?

Most often a PHP execution timeout from updating several plugins at once, or memory exhaustion during file extraction. Other causes are closing the browser mid-update, a full disk, filesystem permissions, or a fatal error in the plugin being updated. The PHP error log at that timestamp usually names it.

Will the maintenance message clear on its own?

Sometimes. WordPress ignores the .maintenance file if the timestamp inside it is more than ten minutes old, so some sites recover by themselves. If yours does not, either something is rewriting the file on each page load or a caching layer is serving a stored copy of the maintenance page.

How do I stop this from happening again?

Update one plugin at a time rather than in a batch, raise max_execution_time and memory_limit if you control them, back up before updating, keep disk space free, and update regularly so each batch is small. Frequent recurrence usually means the hosting environment is too constrained for the site.