Logo
WP Fix by Blimx

WordPress Stuck in Maintenance Mode — Escape Procedures

Actualizado:
ErrorsRecovery

What the message means

When WordPress starts a core, plugin, or theme update, it creates a file called .maintenance in the site root. While that file exists, every request gets the message:

Briefly unavailable for scheduled maintenance. Check back in a minute.

When the update completes successfully, WordPress deletes .maintenance. The site returns to normal.

The problem: if the update fails mid-way — memory error, PHP timeout, network drop — WordPress never reaches the deletion step. The .maintenance file stays. Your site stays in maintenance mode indefinitely.

This article is the escape procedure for every variation we have seen.

Method 1 — Delete the .maintenance file via FTP

The fastest method, works for 95% of cases.

Steps

  1. Connect via SFTP/FTP to your site
  2. Navigate to the WordPress root (where wp-config.php lives)
  3. Find a file literally named .maintenance
  4. Delete it
  5. Refresh your site

That's it. The maintenance message goes away.

Note: Some FTP clients hide dotfiles by default. In FileZilla: Server menu → Force showing hidden files.

Method 2 — Delete via SSH

If you have SSH access:

cd /var/www/yoursite
rm -f .maintenance

Done. Refresh the site.

Method 3 — Delete via WP-CLI

cd /var/www/yoursite
wp maintenance-mode deactivate

WP-CLI handles the deletion safely and confirms.

Method 4 — Delete via hosting file manager

If you have no SSH or FTP access:

  1. Log into your hosting panel (cPanel, Plesk)
  2. Open the File Manager
  3. Enable "Show Hidden Files" in the settings menu
  4. Navigate to public_html/ or your WordPress root
  5. Delete .maintenance

Method 5 — Restore from backup if everything else fails

In rare cases the failed update did more damage than just leaving .maintenance. The site post-deletion shows errors, white screens, or partial functionality. In this case:

  1. Restore the database from your last good backup
  2. Restore files (especially wp-content/) from backup
  3. Re-run the update with proper resource limits

This is destructive — any data created during the failed-update window is lost. Use only when other methods produce a broken site after .maintenance removal.

After deletion: verify integrity

Just deleting .maintenance doesn't guarantee a working site. The interrupted update may have left partial files. Run these checks:

1. WordPress version

wp core version

If the version is what you expected (the target version of the update), the core update completed. If it's the old version, the core update never finished — re-run it.

2. Database schema

wp core update-db

This safely re-runs any pending schema migrations. No-op if everything is done.

3. Plugin integrity

wp plugin list --status=active

For each plugin, verify the version matches what you intended. Some plugins may need reinstall:

wp plugin install <slug> --version=<X.Y.Z> --force

4. File integrity

wp core verify-checksums

This compares your core files against WordPress's published checksums. Any modified or missing file is reported.

Why does an update fail in the first place?

Understanding the cause prevents recurrence:

Cause A — PHP memory exhaustion

The update process loads files in memory. Large updates (WooCommerce, Elementor, BuddyPress) need 256MB+ to complete. Default 128MB hits the wall.

Fix: Set WP_MEMORY_LIMIT in wp-config.php to 512M.

Cause B — PHP execution timeout

Long updates exceed max_execution_time. Default is 30s; some updates need 5 minutes.

Fix: In php.ini:

max_execution_time = 300

Cause C — Network drop while downloading update

WordPress fetches the update package from wp.org. If your server's outbound connection drops mid-download, the file is corrupted.

Fix: Stable DNS resolver and route. For unreliable servers, manually download and place the update file.

Cause D — File permissions wrong

WordPress writes files during update. If permissions are too restrictive, the write fails halfway.

Fix: Ensure directories are 755, files 644, owned by the web server user.

Cause E — Disk full

Out of disk space mid-update. The update writes partial files then dies.

Fix: Free disk space; ensure at least 2GB free before any update.

Prevention checklist

Once you've recovered, make this routine for the next update:

  • [ ] Backup database (wp db export pre-update.sql)
  • [ ] Backup wp-content/ (tar -czf wp-content-backup.tar.gz wp-content/)
  • [ ] Confirm 2GB+ free disk
  • [ ] Confirm PHP memory limit ≥ 512MB
  • [ ] Confirm PHP max_execution_time ≥ 300
  • [ ] Update on staging first if site is business-critical
  • [ ] Update during low-traffic hours
  • [ ] Keep an SSH/FTP session open so you can rescue quickly

Common mistakes after a stuck maintenance

  • Reinstalling WordPress over the broken state — can leave a mix of old/new files
  • Manually editing `wp-config.php` "to fix the database" — usually creates new errors
  • Restoring backup before identifying what failed — loses customer data unnecessarily
  • Trying the same update again without changing anything — same memory/timeout that failed will fail again

When to call a specialist

If you've removed .maintenance but the site is now broken in new ways (white screen, database errors, missing admin), the update did real damage. We recover sites like this every week without losing data when there are backups, and minimize loss when there aren't.

Maintenance mode emergency within minutes. For broader recovery see WordPress emergency support.