Why WordPress Shows This Message at All
When you update WordPress core, a plugin, or a theme from the dashboard, WordPress writes a small file called .maintenance to the site root. The file contains a single timestamp. While it exists, visitors get a 503 response with the text "Briefly unavailable for scheduled maintenance. Check back in a minute." WordPress also sends a Retry-After header of 600 seconds. When the update finishes, WordPress deletes the file.
The file is only a flag, so it does not tell you whether the update succeeded. If the browser tab closed, the server hit a time limit, or a bulk update stalled, the flag can outlive the process that created it.
Step 1: Wait, Then Check from Outside Your Own Browser
If the message appeared in the last few minutes, an update may genuinely still be running. Give it ten minutes, especially for a core update or a bulk plugin update. Then load the site in a private window or on a phone off your Wi-Fi. If the site loads there, the problem is a cached copy in your browser or on a network layer, not the file (see Step 4).
Step 2: Check Whether the .maintenance File Exists
Connect over SFTP or your host's file manager and look in the same folder as wp-config.php. The name starts with a dot, so enable "show hidden files." If you have SSH and WP-CLI, you can check without browsing files:
wp maintenance-mode status
This prints whether maintenance mode is active. If the file is not there but the message still appears, skip to Step 4.
Step 3: Remove the File and Confirm the Update Finished
Once you are sure no update is running, delete .maintenance, or use:
wp maintenance-mode deactivate
Then confirm what actually happened. In the dashboard, open Dashboard → Updates and look for anything still listed as available. With WP-CLI, wp plugin list --update=available shows pending plugin updates, and wp core verify-checksums compares core files against the official release. A failed checksum after an interrupted core update means some core files are partly written. Take a backup, then reinstall core files (wp core download --force --skip-content) or use "Re-install now" under Dashboard → Updates.
If the site now loads but misbehaves, an interrupted plugin update may have left that plugin half-written. Reinstall that plugin from a fresh copy. Do this after a backup, not before.
Step 4: If the Message Persists, Look Beyond the File
Current WordPress core stops honoring a .maintenance file once its timestamp is ten minutes old (see wp_is_maintenance_mode()). A message that persists for an hour is therefore rarely the stale file alone. Check these, in this order:
- Caching layers. Clear the WordPress page-cache plugin, any host-level cache, and your CDN. A 503 page should not be cached, but misconfigured caches can keep serving a copy.
- A maintenance plugin or custom page. Many sites use a maintenance-mode plugin, or a
wp-content/maintenance.phpfile, which WordPress loads in place of the default message. Search the codebase for the phrase to see where it comes from. - Repeated update attempts. An auto-update that keeps failing can recreate
.maintenanceeach time it retries. Look at Dashboard → Updates and the host's cron or auto-update settings. - Your host. Some hosts put a site into their own maintenance state during migrations or account issues. If the exact words do not match the default WordPress message, contact the host.
Step 5: Find Out Why the Update Failed
If the same update keeps failing, check the PHP error log or the WP_DEBUG_LOG output (wp-content/debug.log). Common causes are a low PHP time limit or memory limit (see our memory exhausted guide), a full disk, or file ownership that stops WordPress from replacing files. Bulk-updating many plugins at once makes timeouts more likely; update them one or two at a time. If a plugin conflict is behind it, see plugin not working in WordPress.
What This Does to Your Search Visibility
The 503 status and Retry-After header tell search engines the outage is temporary. Google's documentation on HTTP status codes and network errors says server errors make its crawlers slow down, and URLs that persistently return server errors are eventually dropped. A few minutes is harmless. Days is not.
Preventing It Going Forward
Back up before updating. Update in small batches. Do not close the tab mid-update. Test major plugin and core updates on a copy of the site first. If your site earns money or takes inquiries, run updates in a low-traffic window with someone watching the result. Our piece on why WordPress updates need a process, not just a click covers this in more detail. For the wider picture, see the guide to WordPress errors.
