Fixing “Briefly Unavailable for Scheduled Maintenance. Check Back in a Minute” in WordPress

You updated WordPress, a plugin, or a theme, and now every page says: Briefly unavailable for scheduled maintenance check back in a minute. If that WordPress maintenance message has been sitting there for more than a few minutes, WordPress is probably stuck in its temporary update mode after one of the common WordPress update problems.

This is usually not a hack, lost content, or a broken database. It is more often one small hidden file that WordPress forgot to remove after an interrupted update.

TL;DR: If the message has been stuck for more than a few minutes, delete the hidden .maintenance file from the WordPress root folder. Then clear cache and check the failed update, because removing the message does not prove the update finished.

Start here: wait or fix it

Do not delete anything if the update started a few seconds ago. WordPress uses maintenance mode during normal updates so visitors do not see files while they are being replaced.

If the message is still there after 5 to 10 minutes, move to the file fix.

What is happening	What to do
The update just started	Wait a few minutes, then refresh once.
The message has been stuck for 5 to 10 minutes	Delete .maintenance from the WordPress root folder.
You cannot access wp-admin	Use your host file manager, SFTP, FTP, SSH, or WP-CLI.
You cannot find .maintenance	Show hidden files and confirm you are in the WordPress root folder.
The file is gone but the message remains	Clear browser, plugin, host, and CDN cache.
The site loads but looks broken	Check the update before you move on.

The most common mistake is stopping when the page loads again. Deleting .maintenance opens the site. It does not prove that WordPress, the plugin, or the theme updated cleanly.

Why this message appears

During a core, plugin, or theme update, WordPress creates a temporary hidden file named .maintenance in the WordPress root folder. The root folder is the same place where you usually see wp-config.php, wp-admin, wp-content, and wp-includes.

That file tells WordPress to show the temporary maintenance screen instead of loading the site mid-update. In our clean WordPress 6.9.4 test site, an active .maintenance file returned HTTP 503 with Retry-After: 600. Removing the file restored HTTP 200.

That 503 response is normal for a short update window. It tells browsers and search engines that the outage is temporary.

Where this goes wrong is simple: the update gets interrupted before WordPress removes the file. A browser tab closes, a bulk update times out, a server runs low on resources, permissions block a file change, or one plugin update fails halfway through.

Delete the hidden maintenance file

If the message is clearly stuck, deleting .maintenance is the main fix. You are removing a temporary update flag, not your posts, pages, users, settings, media, plugins, or theme.

If you have a quick backup option, use it before deeper repairs. Do not let that delay the basic .maintenance fix, but do make a backup before renaming plugin folders or repairing failed updates.

Access method	Use it when	Watch for
Hosting file manager	You want the easiest route	Hidden files may be turned off.
SFTP or FTP	Your host file manager is hard to use	Dotfiles may be hidden by default.
WP-CLI over SSH	You are comfortable with the command line	You must run it from the WordPress root.
LocalWP or macOS Finder	The issue is on a local site	LocalWP roots are often inside app/public.

Use your host file manager

If you manage several domains from one hosting account, slow down at the root-folder step. Deleting the file from the wrong site will not fix the site that is down.

After the temporary file is removed, the frontend should load normally again.

Use SFTP or FTP

If every tutorial says the file exists and you cannot see it, hidden files are the first thing to check. This tiny setting causes a lot of wasted time.

Use WP-CLI

If you have SSH access and WP-CLI installed, go to the WordPress root folder and run the maintenance-mode deactivate command.

You can also run a core version check first to confirm you are in the right install. If WP-CLI does not recognize the site, you are probably in the wrong folder.

Fix a LocalWP or macOS site

For LocalWP, open the local site files and look for the WordPress root, commonly app/public. On macOS, press Command + Shift + Period in Finder to show hidden dotfiles.

Then delete .maintenance from the WordPress root and reload the local site.

If you cannot find the file

Do not jump straight to disabling plugins. In most cases, the file is hidden, you are in the wrong folder, or the old maintenance page is cached. Check these in order:

WordPress uses a timestamp inside .maintenance. In our test site, a current timestamp triggered the message. A timestamp older than 10 minutes did not.

That does not mean every stuck screen fixes itself after 10 minutes. Cache, a maintenance plugin, a custom maintenance page, or a host-level page can keep showing a similar screen.

If the message remains

At this point, you may not be dealing with native WordPress update maintenance anymore. If the screen has different behavior, treat it as a broader WordPress stuck in maintenance mode problem. First, confirm .maintenance was deleted from the correct root folder and purge every cache layer you use.

Then look closely at the page. The native message is plain: “Briefly unavailable for scheduled maintenance. Check back in a minute.” Different wording, a logo, a countdown, a styled page, a contact form, or host branding usually points to another cause:

If .maintenance keeps coming back, stop deleting it in a loop. The update process is failing again, so the real problem is the update, server limit, permission issue, or plugin/theme conflict behind it.

Check the update after the site loads

This is the step that protects you from a second problem. The site can load even when the original update did not finish correctly. The Updates screen is the first place to check whether WordPress still sees unfinished core, plugin, or theme updates.

Use this quick check:

For plugin updates, use the plugin list to confirm the installed version and rerun only the failed item.

For WooCommerce, membership, LMS, booking, or donation sites, test the money or signup path before you assume the site is fine. A page load is not the same as a working business flow.

If the update broke the site

If the maintenance message is gone but the site now has a fatal error, white screen, broken layout, or inaccessible admin area, treat it as failed update recovery.

Start with a backup. If files look damaged or you are unsure what changed, restoring a clean backup is often safer than editing plugin or theme files under pressure. WPRemote can help here if you already use it for backups and need a cleaner way to restore a recent WordPress backup than guessing which half-updated file caused the break.

Use the narrowest repair first:

Symptom	Likely cause	Safer next step
One feature broke	Plugin update failed or introduced a conflict	Check that plugin version, then rerun or roll back carefully.
wp-admin shows a fatal error	Plugin or theme PHP error	Check error logs, then disable the likely plugin or theme.
Frontend has no styling	Theme or asset update failed	Clear cache, verify the active theme, and check for visual regression after updates.
Updates keep timing out	Server limit, permission issue, or disk space problem	Check PHP memory, execution time, permissions, ownership, and disk space.
.maintenance keeps returning	The update process keeps failing	Stop bulk updates and isolate the failing item.

If a plugin is the likely cause and wp-admin is unavailable, rename that specific plugin folder inside wp-content/plugins. Rename the whole plugins folder only when you do not know the culprit and you have a backup or staging copy.

For theme failures, switch to a default theme from the dashboard if you can. If you cannot access the dashboard, ask your host or hire a WordPress freelancer to help switch the active theme safely.

The Themes screen helps you verify which theme is active before you make a recovery change.

Prevent it next time

The best fix is not getting faster at deleting .maintenance. The best fix is making updates less likely to fail. Use these habits:

Site Health is a useful follow-up screen when repeat failures point to server limits or configuration issues.

For a simple brochure site, smaller batches and a current backup may be enough. For a WooCommerce store, membership site, LMS, or agency-managed client site, a failed update can block revenue or client work.

WPRemote fits after the emergency is over. It helps you test WordPress updates safely, keep backups ready, and monitor site health across updates. That matters most when you manage several sites and cannot watch every update by hand.

Does this hurt SEO?

A short native maintenance window is usually not an SEO problem. WordPress returns a temporary 503 response, which tells search engines to come back later.

Extended downtime is different. If the message stayed up for hours, fix the site, check important pages, and review Search Console, server logs, or WordPress uptime monitoring if organic traffic matters to the site. If uptime alerts do not match what you saw, rule out site uptime monitor false reports before treating it as a fresh outage.

A brief 503 is normal. A stuck maintenance page is downtime.

FAQs

Is it safe to delete the maintenance file?

Yes, once the update is clearly stuck. .maintenance is a temporary update flag, not your content, settings, users, media, plugins, or theme.

Where is the maintenance file in WordPress?

It is in the WordPress root folder. That is usually the same folder as wp-config.php, wp-admin, wp-content, and wp-includes.

Why can’t I see the maintenance file?

It is hidden because the filename starts with a dot. Turn on hidden files or dotfiles, then confirm you are in the correct WordPress root folder.

What if wp-admin is also unavailable?

Use file-level access. Your host file manager, SFTP, FTP, SSH, or WP-CLI maintenance mode commands can remove the file without dashboard access.

Do I need to run the update again?

Yes, if WordPress still shows the update or the version number did not change. Deleting the file restores access. It does not finish a failed update.

Final check

Before you move on, confirm the update completed, test the important parts of the site, and clear cache. On managed sites, keep a WordPress plugin update report so you can see what changed. If the site still looks wrong, treat it as a failed update instead of a maintenance-mode problem.

The useful rule is simple: remove .maintenance to reopen the site, then verify the update so the same problem does not return.