Your WordPress site is showing: "Briefly unavailable for scheduled maintenance. Check back in a minute." You've waited more than a minute. The message isn't going away. This guide covers the immediate fix, what caused the stuck message, how to verify the underlying update completed, and how to prevent it happening again.
WordPress enters maintenance mode automatically at the start of every update, core, plugins, or themes. It does this by creating a hidden file named .maintenance in the root of your WordPress installation (the same folder as wp-config.php). As long as that file exists, WordPress displays the maintenance message to all visitors and temporarily redirects wp-admin.
When the update finishes successfully, WordPress deletes the .maintenance file and the site returns to normal. The stuck maintenance message means the update process was interrupted before it could delete the file. Common causes: you closed the browser tab mid-update, your server hit a PHP execution time limit, you lost your internet connection, or a PHP error occurred partway through the process.
Connect to your server via FTP or your hosting control panel's file manager. Navigate to the root of your WordPress installation. Look for a file named .maintenance and delete it. The maintenance message disappears immediately, no server restart or cache flush required.
If you don't see the file, check that hidden files are visible. The leading dot makes it a hidden file on Unix systems. In cPanel's File Manager, click the Settings button in the top right and check "Show Hidden Files (dotfiles)". In FTP clients like FileZilla, go to Server > Force Showing Hidden Files. In Cyberduck, use View > Show Hidden Files.
Once visible, the file will be listed right alongside wp-config.php and .htaccess. Delete it, then reload your site.
Deleting .maintenance fixes the stuck message but doesn't tell you whether the update finished. After the message clears, log into wp-admin and go to Dashboard > Updates. If the update is still listed as available, the process was interrupted and didn't complete.
An interrupted update may have left partially updated files on disk, some files from the new version, some from the old version. Running the update again from this state is generally safe for plugins and themes, but for a WordPress core update, the safest approach is to restore from your most recent backup first, then run the update from a clean starting point.
If the update no longer appears in Dashboard > Updates, it completed successfully before the interruption that left the .maintenance file. You're done, the fix was just deleting the file.
The maintenance message affects wp-admin in some server configurations. If you can't reach the login screen, delete .maintenance first. That should restore wp-admin access immediately.
If wp-admin is still inaccessible after removing the file, the interrupted update likely produced a PHP error. Check your server error logs, in cPanel this is under Metrics > Errors, or in the Logs section depending on your version. Look for PHP fatal errors timestamped around when the update was attempted. A corrupted plugin file is the most common culprit. If you can identify the plugin, rename or delete its folder via FTP to force-deactivate it, then access wp-admin and run a clean reinstall.
If the update was interrupted because your server's PHP execution time limit is too low, the same problem will recur on the next large update. WordPress needs enough time to download, verify, and extract update packages. A limit of 30 seconds is usually sufficient for plugin updates; core updates may need 60+ seconds on slower connections.
You can check and increase the limit via php.ini, .htaccess, or wp-config.php. In wp-config.php, you can set:
@ini_set( 'max_execution_time', 300 );This sets a 5-minute limit via PHP's ini_set, which is sufficient for all routine WordPress updates. Some hosts don't allow ini_set changes; in that case, use a php.ini file in your root directory or contact support to raise the limit at the server level.
If you've enabled automatic background updates (either via WordPress core's built-in auto-update or a management plugin), interrupted updates can happen without you being present to notice. In this case, your site may have been showing the maintenance message for hours before you spot it.
For automatic updates to complete reliably, your server needs adequate PHP execution time, a stable connection from the server to WordPress.org (not your browser), and no resource throttling that would kill PHP processes mid-execution. If you're on a shared host that aggressively kills long-running PHP processes, background updates are inherently unreliable, consider disabling them and running updates manually on a schedule instead.
The core prevention measures are: never close the browser tab during an update, maintain a stable internet connection while updates run, and use staging before applying updates to live sites. For automated updates, ensure your server's PHP execution time limit is generous enough for the largest updates you're running.
Using a staging environment to test updates before they go live also means that if an update does cause a problem, not just a stuck maintenance file, but a real compatibility issue, you discover it on staging rather than on the live site. Most managed WordPress hosts offer one-click staging. If yours does, there's no reason not to use it for every significant update.
Test updates on staging first. If a live update goes wrong, restore the previous version in under two minutes with automated daily backups.
View Hosting Plans