How to Fix 'Briefly Unavailable for Scheduled Maintenance' in WordPress

You try to load your site and instead of your homepage you see a plain white page with one line of text: "Briefly unavailable for scheduled maintenance. Check back in a minute." So you wait a minute. Then five. Then ten. It never comes back.

This is one of the most common WordPress errors, and the fix takes about thirty seconds once you know what to look for. But if you don't understand why it happened, it will keep happening — especially if you're running WooCommerce or managing multiple plugin updates at once.

What actually causes this message

When you click "Update" on a plugin, theme, or WordPress core, the first thing WordPress does is create a file called .maintenance in your site's root directory. That file contains a single line of PHP:

<?php $upgrading = 1714732800; ?>

That number is a Unix timestamp — the exact second the update started. While this file exists, WordPress intercepts every incoming request and shows the "Briefly unavailable" message instead of loading your site. It is a lock designed to prevent visitors from seeing a half-updated site.

Under normal conditions, the update finishes in a few seconds, WordPress deletes the .maintenance file, and your site comes back online. The problem happens when the update process gets interrupted before it can clean up after itself. The .maintenance file stays behind, and your site stays locked.

Since WordPress 4.6, there is a built-in safety net: if the .maintenance file is more than 10 minutes old, WordPress ignores it and loads normally. But that only works if the timestamp inside the file is valid and the rest of the update actually completed. If files were half-written or the database upgrade didn't finish, you may have bigger problems than just the lock file.

The most common reasons updates get interrupted

PHP timeout. Most shared hosting plans set PHP's max_execution_time to 30 seconds. A large plugin update — especially WooCommerce, which has dozens of files and often runs database migrations — can easily exceed that. PHP kills the process, the .maintenance file stays, and the update is incomplete.

Bulk updates. Clicking "Update All" on a page with 15 pending plugin updates is tempting but risky. WordPress processes them sequentially in a single request. If any one plugin takes too long or hits an error, the entire chain stops and the lock file remains.

Browser tab closed. The update process runs server-side, but the admin UI tracks progress via AJAX polling. Closing the tab doesn't kill the server process immediately, but on some hosting configurations (especially with PHP-FPM's fastcgi_finish_request), it can cause the cleanup step to be skipped.

Low memory. If PHP runs out of memory mid-update, the process crashes. WordPress's default memory limit of 40MB is often not enough for large plugin updates. WooCommerce alone recommends at least 256MB.

Server-level issues. An Apache or Nginx restart, a brief database outage, or a hosting provider performing maintenance at exactly the wrong moment can all interrupt an in-progress update.

How to fix it right now

Step 1: Delete the .maintenance file

Connect to your site via SFTP, your hosting provider's File Manager, or SSH. Look in the WordPress root directory — the same folder that contains wp-config.php and wp-content/. You should see a file called .maintenance.

Because the filename starts with a dot, it is hidden by default on most systems. In your SFTP client, enable "Show hidden files" (in FileZilla: Server > Force showing hidden files). In cPanel File Manager, click Settings and tick "Show Hidden Files."

Via SSH:

ls -la /path/to/wordpress/.maintenance

Delete it:

rm /path/to/wordpress/.maintenance

Your site should come back immediately. Load it in a browser and check both the frontend and the admin dashboard.

Step 2: Check whether the update actually completed

Deleting the lock file brings your site back online, but it doesn't mean the interrupted update finished cleanly. Log into wp-admin and go to Dashboard > Updates. If the plugin, theme, or core update still shows as pending, it didn't complete.

Check the Plugins page too. WordPress may show a notice like "The plugin has been deactivated due to an error" or the plugin version number may be the old one.

If a core update was interrupted, you can end up with a mix of old and new files. The most reliable fix is to re-run the update. Via WP-CLI:

wp core update --force --path=/path/to/wordpress

If a plugin update was interrupted, re-run it:

wp plugin update woocommerce --path=/path/to/wordpress

Or from the dashboard: go to Plugins > Installed Plugins, and run the update again.

Step 3: Check the database

Some updates include database schema changes. WooCommerce does this frequently — adding columns, creating new tables, migrating order data. If the update was interrupted mid-migration, your database might be in an inconsistent state.

After re-running the update, watch for a notice in wp-admin saying "WooCommerce database update required." Click "Update WooCommerce Database" and let it run. For large stores, this can take several minutes.

For core updates, WordPress automatically checks the database version on admin load. If it detects a mismatch, it redirects you to /wp-admin/upgrade.php. Follow the prompts.

If your site seems broken even after re-running updates, check the error log:

tail -50 /path/to/wordpress/wp-content/debug.log

If debug.log doesn't exist, you can enable it temporarily by adding this to wp-config.php:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

How to prevent this from happening again

Update plugins one at a time, not in bulk

I know clicking "Select All > Update" is faster, but it's the single biggest cause of stuck maintenance mode on the sites I manage. If plugin three out of fifteen crashes, plugins four through fifteen don't get updated, and you have no idea which one caused the failure.

Update them individually. It takes longer, but you'll know immediately if something breaks.

Increase PHP limits for updates

Add these to wp-config.php before the "That's all, stop editing" line:

define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');

WP_MEMORY_LIMIT applies to the frontend. WP_MAX_MEMORY_LIMIT applies to wp-admin, where updates run. If your hosting provider caps memory lower than this at the server level, these constants won't override it — contact your host to increase the PHP memory_limit.

Also check max_execution_time. For updates, 120 seconds is a reasonable minimum. You can check your current limit by going to Tools > Site Health > Info > Server.

Use WP-CLI for updates

If you have SSH access, WP-CLI is the most reliable way to update plugins and core. It runs from the command line, isn't affected by browser timeouts, and gives you clear error output when something fails.

Update all plugins with output:

wp plugin update --all --path=/path/to/wordpress

The advantage is that WP-CLI still creates and removes the .maintenance file, but it's not subject to PHP's web timeout limits. A plugin update that would time out at 30 seconds in the browser can take as long as it needs via CLI.

Control auto-updates carefully

WordPress has auto-updated minor core releases (security and maintenance releases) since version 3.7. Since WordPress 5.6, you can also enable auto-updates for plugins and themes from the dashboard.

Auto-updates run via wp-cron, which means they're subject to the same timeout issues as manual updates — but nobody is watching when they run. If a 2 AM auto-update gets stuck, your site sits in maintenance mode until someone notices.

To disable plugin and theme auto-updates entirely, add to wp-config.php:

define('AUTOMATIC_UPDATER_DISABLED', false);
add_filter('auto_update_plugin', '__return_false');
add_filter('auto_update_theme', '__return_false');

Or more selectively, keep core auto-updates but disable them for plugins. Add to your theme's functions.php or a site-specific plugin:

add_filter('auto_update_plugin', '__return_false');
add_filter('auto_update_theme', '__return_false');

I prefer managing updates manually during business hours when I can monitor the result. For the 70+ sites I maintain, I use WP-CLI scripts that update one site at a time, verify the site loads correctly after each update, and alert me immediately if something breaks.

Take a backup before every update

This should be automatic, not something you remember to do manually. If your hosting provider doesn't offer pre-update snapshots, a plugin like UpdraftPlus or a server-level backup running daily gives you a rollback point.

Via WP-CLI, you can export the database before updating:

wp db export /backups/pre-update-$(date +%Y%m%d).sql --path=/path/to/wordpress
wp plugin update --all --path=/path/to/wordpress

If the update goes wrong, you have a clean database to restore from.

Customising the maintenance page

The default maintenance message is bare and unhelpful. You can replace it by creating a file called maintenance.php (not .maintenance) in your wp-content/ directory:

<?php
http_response_code(503);
header('Retry-After: 120');
?>
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Maintenance in Progress</title>
</head>
<body>
    <h1>We'll be right back</h1>
    <p>We're performing a scheduled update. This usually takes less than a minute.</p>
</body>
</html>

WordPress checks for wp-content/maintenance.php before showing its default message. The 503 status code tells search engines the downtime is temporary, and the Retry-After header suggests they check back in 120 seconds. This prevents search engines from indexing or deranking your site during brief maintenance windows.

When it's more than just a stuck file

If deleting .maintenance doesn't bring your site back — or if the site comes back but with errors — the update probably caused real damage. Common symptoms:

• White screen after deleting .maintenance: a plugin or core file was partially written. Check the white screen of death guide for systematic debugging steps.
• "Error establishing a database connection": the database update may have corrupted a table. Check your database credentials in wp-config.php and try running wp db repair if you have WP-CLI access.
• Site loads but plugin is broken: the plugin files updated but its database migration didn't complete. Deactivate and reactivate the plugin, or check for a pending database update notice in wp-admin.
• Critical Error / Recovery Mode email: WordPress 5.2+ will email you a recovery link. Check your inbox. The email identifies exactly which plugin or theme caused the fatal error. I've covered what to do when a plugin update breaks your site in detail.

If you're dealing with a WooCommerce store that went down during an update, the stakes are higher — every minute of downtime is lost revenue. Don't experiment. Restore from backup first, then run the update in a staging environment to identify the problem before trying again on production.

---

Stop Firefighting. Start Maintaining.

I manage 70+ WordPress sites for agencies and businesses. Whether you need ongoing maintenance, emergency support, or a one-off performance fix — I can help.

View Maintenance Plans → Get in Touch →