How to Fix “Briefly Unavailable for Scheduled Maintenance” in WordPress (2026)

WordPress will auto-recover from this error after exactly 10 minutes. Most site owners find that out the hard way, after panicking through the first nine. The faster fix is manual: delete the .maintenance file in your site’s root folder. No waiting required.

Quick answer: Find the .maintenance file in your WordPress root folder and delete it. Use FTP, your hosting File Manager, or one WP-CLI command if you have terminal access. Site comes back the second the file is gone.

Last reviewed: April 2026. Methods verified against WordPress 6.8+ and tested across cPanel, Plesk, hPanel, and DirectAdmin.

What’s Actually Happening (And Why It’s Not Really an Error)

WordPress drops a hidden file called .maintenance into your site’s root folder every time it updates core, a plugin, or a theme. Open it in a text editor and you’ll see exactly one line of PHP: <?php $upgrading = 1714208400;. That number is the Unix timestamp of when the update started. WordPress reads it on every page load to decide whether to serve your site or the maintenance message. While the file is active, every request returns HTTP 503 (Service Unavailable), which is why Google’s crawler and most uptime monitors handle the error gracefully without flagging your site as down.

Under normal conditions, the file lives for five to fifteen seconds. WordPress writes it the moment an update begins and deletes it the second updates finish. You probably never see it.

Here’s the part most fix guides skip: WordPress core checks that timestamp on every page load and automatically bypasses the maintenance message if it’s more than 10 minutes old. The site recovers on its own at the 10-minute mark, even if the file still exists. The exact check lives in the wp_is_maintenance_mode() function, and the constant is hardcoded. So if you arrived here within minutes of the error appearing, deleting the file is the fastest path back online. If it’s been an hour and you’re still stuck, something else is wrong: a caching layer, CDN edge, or browser cache is probably serving the maintenance page from storage. Clear those before you start touching files.

But updates fail. A lot. The browser tab gets closed mid-update. The server times out on a slow shared host. You hit “Update All” with 14 plugins queued, and one of them throws a fatal PHP error. The .maintenance file gets written, the update breaks, and nothing ever cleans it up. The site stays offline (or partially offline) until you remove the file yourself.

Common triggers in real-world reports

• Bulk-updating multiple plugins or themes at once on shared hosting
• Closing the browser or losing your internet connection mid-update
• A plugin with a PHP fatal error stopping the update sequence
• Server timeouts on hosts with strict execution time limits (often 30 seconds or less)
• Running out of disk space or PHP memory during the update
• Auto-updates firing while another update is already in progress

If you arrived here from one of these scenarios, the actual fix takes about 60 seconds. Pick whichever method below matches the access you have.

Method 1: Delete the .maintenance File Using FTP

Most fixes happen here. FTP works on every host whether you have shell access, dashboard access, or neither. You only need an FTP client and the credentials your host emailed you when you signed up.

What you’ll need

• An FTP client (FileZilla, Cyberduck, or WinSCP all work)
• Your hosting FTP/SFTP credentials (host, username, password, port)
• About two minutes (less if your FTP client is already open, which it should be for any WordPress site you actually run)

The steps

1. Open your FTP client and connect to your site. Most modern hosts use SFTP on port 22, not classic FTP on port 21. Check your hosting welcome email if you’re not sure.
2. Navigate to your WordPress root directory. This is the folder containing wp-config.php, wp-admin, wp-content, and wp-includes. On most shared hosts it’s called public_html or www.
3. Look for a file named .maintenance. Files starting with a dot are hidden by default. In FileZilla, click Server, then Force Showing Hidden Files. In Cyberduck, press Cmd+Shift+R (Mac) or Ctrl+Shift+R (Windows).
4. Right-click the .maintenance file and select Delete.
5. Refresh your site in a new browser tab. It should load normally.

Don’t see the file at all? Your site might have already cleared it but cached the maintenance page. Clear your browser cache and any caching plugin’s stored output, then refresh.

Method 2: Use Your Hosting File Manager

No FTP client installed? Most hosting control panels let you delete files straight from the browser. The exact path varies by panel, so here’s how it works on the four most common ones.

cPanel

1. Log into cPanel
2. Open File Manager
3. Click Settings (top right), tick Show Hidden Files (dotfiles), then save
4. Navigate to public_html
5. Right-click .maintenance and choose Delete

Plesk

1. Log into Plesk
2. Click Files in the left sidebar
3. Open httpdocs (or the document root for your domain)
4. Click the gear icon and enable Show Hidden Files
5. Select .maintenance and click Remove

hPanel (Hostinger)

1. Log into hPanel
2. Open File Manager
3. Toggle Show Hidden Files in Settings
4. Navigate to public_html
5. Right-click .maintenance and choose Delete

DirectAdmin

1. Log into DirectAdmin
2. Open File Manager under System Info & Files
3. Enable Show Hidden Files in the toolbar
4. Browse to public_html
5. Tick .maintenance and click Delete

The file itself is identical across all panels. Same one-line PHP, same handful of bytes. You’re just hunting for it in four different interfaces. Whichever panel you use, the result is the same: file gone, site back.

Method 3: One WP-CLI Command (For Developers)

SSH access plus WP-CLI installed? This is the fastest fix on the page. SSH in, switch to your WordPress directory, and run:

wp maintenance-mode deactivate

You’ll see “Success: Deactivated Maintenance mode.” That’s the entire procedure. The .maintenance file gets removed and your site is back online.

The wp maintenance-mode command shipped with WP-CLI 2.6, so any current install supports it. If you get a “command not found” message, your host probably hasn’t installed WP-CLI globally. Use Method 1 or 2 instead.

Kinsta, WP Engine, Rocket.net, and Pressable all ship with WP-CLI pre-installed and expose it through their dashboard terminal or tools panel. No SSH keys required. Other providers in our managed WordPress hosting USA roundup behave the same way. If you’re paying for managed WordPress, this 30-second fix is the actual reason.

Method 4: SSH Without WP-CLI

Got SSH access but no WP-CLI? Two commands handle it:

cd /path/to/your/wordpress
rm .maintenance

That’s the whole fix. The path looks like /home/username/public_html on cPanel-style hosts and /var/www/html or /var/www/yoursite.com on most VPS setups.

Most shared hosts disable SSH by default. If your terminal returns “Connection refused” or “Permission denied,” your hosting plan doesn’t include shell access. Either request it from support (some hosts enable it on demand) or skip back to Method 1 or 2.

If rm reports the file doesn’t exist, run ls -la and check what’s actually there. Sometimes the file appears with a slightly altered name (like .maintenance.old) from a half-successful previous attempt. Delete whichever variant you find.

When the .maintenance File Keeps Coming Back

Here’s an annoying scenario: you delete the file, refresh, the site loads, you celebrate, and 15 seconds later the error returns.

This means an automatic update is still running in the background, repeatedly creating the file. Or a stuck cron job is firing the same broken update every minute.

Three things to check:

1. Disable WordPress auto-updates temporarily by adding this line to wp-config.php: define(‘AUTOMATIC_UPDATER_DISABLED’, true);
2. Check wp-content for a .maintenance file there too. It’s less common, but it does happen.
3. Run wp cron event list and look for anything firing every minute or every five minutes. Disable suspicious events with wp cron event delete.

Seeing PHP errors in the maintenance message itself, or in wp-content/debug.log? That’s a different problem. A plugin update probably broke something. You’ll need to deactivate the offending plugin by renaming its folder in wp-content/plugins, then update it manually through the dashboard once the site loads.

How to Prevent This Error From Happening Again

The fix itself is easy. Avoiding the situation in the first place is more useful.

Update one thing at a time

WordPress lets you select 30 plugins and click Update. Don’t. If any one of them throws a fatal error or hits a slow database query, the whole batch fails and the .maintenance file stays. Update plugins one by one, refresh between each, and you’ll rarely see this error again.

Run updates from desktop, not mobile

Mobile browsers timeout, switch tabs, and lose connection more often. If WordPress kills the update process before it finishes, the .maintenance file stays put. Use a desktop browser on a stable connection. Boring advice. Saves real headaches.

Back up before updating

Not directly preventing the error, but it makes the next 20 minutes a lot calmer when one update breaks something. UpdraftPlus, BlogVault, and BackWPup all run on free tiers. Or use your host’s daily automated backup if it has one. Restore from the last good snapshot if a fix takes longer than rolling back.

Choose hosting that handles updates well

Cheap hosts cause this error more often than managed WordPress hosts, and the reason is one number: max_execution_time. Budget shared plans typically default to 30 seconds. Mid-tier shared sits around 60. Managed WordPress hosts like Kinsta and WP Engine ship with 300. The difference matters when you update a plugin that runs a database migration: 30 seconds regularly fails halfway, 300 finishes comfortably. If the error keeps coming back week after week, the host is the problem, not WordPress. Our shared hosting comparison flags the providers with reasonable PHP limits.

Bigger sites outgrow shared plans entirely. A WordPress VPS gives you dedicated resources, your own PHP timeout, and enough memory to update 20 plugins without breaking. The same site that fails an update once a week on a USD 3/mo shared plan often updates flawlessly on a USD 15/mo VPS.

Use staging for risky updates

A staging site is a clone of your live site where you test updates before pushing them to production. Most managed hosts include one-click staging in their plans. Test the plugin update there first. If it breaks staging, you know to fix it before risking production. Many AI WordPress builder platforms now bundle staging into their free tier too.

Frequently Asked Questions

How long does “Briefly Unavailable for Scheduled Maintenance” actually last?

Under normal conditions, 5 to 15 seconds. WordPress writes the .maintenance file when updates begin and removes it the moment they finish. After exactly 10 minutes, WordPress auto-bypasses the message even if the file is still there, since core treats anything older as a failed update. Still stuck past 10 minutes? It’s almost always a caching layer holding the old response. Clear cache first, then delete the file manually if needed.

Where is the .maintenance file located?

Always in your WordPress root directory, alongside wp-config.php and the wp-admin folder. On most shared hosts that’s public_html or www. On VPS setups it’s usually /var/www/html or /var/www/yoursite.com. The file is hidden because it starts with a dot, so enable “Show Hidden Files” in your FTP client or File Manager before you go looking.

Can I bypass the maintenance message without deleting the file?

Sort of. Adding a query string to your URL won’t help, since the maintenance check runs server-side. But if you have admin access, navigate directly to /wp-admin/upgrade.php and run the upgrade routine. Sometimes that completes the stuck update and removes the file naturally. For most people, deleting the file directly is faster and more reliable.

Will deleting .maintenance break my site?

No. The file only exists during updates. Removing it stops WordPress from showing the maintenance page. But if the actual update was incomplete, your real problem is the broken plugin or theme that triggered the timeout. Check your site after deletion. If you see a different error like a white screen or fatal PHP error, the update never finished. You’ll need to roll back the offending plugin manually or update it again from a clean state.

Why does this happen on some sites and never on others?

Two factors decide it: how many plugins you update at once, and how generous your host’s PHP timeout is. A site with 5 plugins on a managed host with a 300-second timeout almost never hits this error. A site with 40 plugins on a budget shared host with a 30-second timeout hits it constantly. If you’ve moved hosts and the problem disappeared, it was the old host all along.

Does this error affect SEO?

If it lasts under 10 minutes, no. Google’s crawler retries pages that respond with HTTP 503 (which is what WordPress sends during maintenance), and a few minutes of downtime won’t move rankings. If the error stretches into hours or days, you might see a temporary drop in cached pages until the crawler returns. Resolve it quickly and rankings recover within a day or two.

Is there a plugin that prevents this error automatically?

Plugins like WP Maintenance Mode and Maintenance let you control the maintenance screen, but they don’t prevent the underlying file-stuck issue. The error happens before any plugin can run, since WordPress checks for .maintenance at the very top of every request. Prevention is about update workflow and host quality, not a plugin you install.

Final Thoughts

“Briefly Unavailable for Scheduled Maintenance” is the most misleading error message in WordPress. There’s no scheduling. There’s no maintenance. There’s a one-line PHP file that should have been deleted three milliseconds after the update finished, and a 10-minute timer that core uses to dig itself out anyway. Once you understand that, fixing it is a 60-second job.

One-off occurrence? Delete the file and move on with your day. Seeing it every Tuesday after auto-updates? The problem is upstream. The pattern is almost always one of three things: a single plugin that always times out, a host with a 30-second PHP limit it won’t raise, or an auto-update schedule running while users are still on the site.

For sites where uptime is the actual product, a host that handles updates safely earns back the price difference within months. Once this fix is behind you, our free WordPress migration guide walks through moving to a host with proper PHP timeouts and pre-installed WP-CLI without losing a single visitor in the process.