WordPress stuck in maintenance mode
Recognizing the blockage: most common symptoms and scenarios
You were updating WordPress, a theme, or a plugin, and suddenly your site displays a message like Briefly unavailable for scheduled maintenance (or a custom maintenance page). Sometimes only the front end is affected, sometimes even access to the admin becomes unstable. In most cases, it isn’t a mysterious outage: WordPress activates a maintenance mechanism during updates, then deactivates it automatically at the end. The problem occurs when this return to normal doesn’t happen.
This blockage usually appears after an interrupted update (tab closed too early, lost connection, memory limit, server timeout), after a batch of chained updates, or when a cache/security plugin interferes with the requests required by the process. Another common case: slow or overloaded hosting at the moment of unpacking packages or writing files, which leaves WordPress in a state "in between".
Why WordPress stays stuck in maintenance (what’s really happening)
During an update, WordPress creates a temporary file named .maintenance at the site root (at the same level as wp-config.php). As long as this file exists, WordPress considers the site to be in maintenance and displays the corresponding message to visitors (or redirects to a maintenance page).
Normally, this file is deleted automatically as soon as the update finishes. If it remains in place, it means a step failed: unable to write files, scripts interrupted, insufficient permissions, lack of disk space, or a conflict with a plugin that blocks execution. In some cases, the file is deleted but an incomplete update has broken a plugin, a theme, or even core, causing another form of failure (500 error, white screen, redirect loop), which gives the impression of a "permanent" maintenance.
Immediate action: disable maintenance mode by deleting .maintenance
The quickest solution is to delete the file .maintenance. To do this, use FTP/SFTP (FileZilla, WinSCP), or your host's file manager (cPanel, Plesk, etc.). Show hidden files if necessary (files starting with a dot are not always visible). Typical steps:
1) Connect to the root of your site (folder where wp-admin, wp-content, wp-includes are located).
2) Locate
3) Delete it (or temporarily rename it to .maintenance.
.maintenance_old .maintenance_old to test without losing info).
4) Reload your site in private browsing.
If you want a step-by-step illustrated guide, this resource clearly explains the procedure: disable tutorial via the .maintenance file.
If the site does not come back: check if an update failed
Delete .maintenance only removes the maintenance banner. If an update was interrupted, there may be partially copied files, a database waiting to be upgraded, or a plugin that has become incompatible. You may then observe:
Discover our offers for WordPress website maintenance
• a 500 error (Internal Server Error);
• a blank page;
• a WordPress critical error;
• an inaccessible back office ;
• missing features (editor, media, widgets).
In this case, enable debug mode to get guidance: in wp-config.php, go to WP_DEBUG set to true and log to a file (do not display in production if possible). Then check wp-content/debug.log. Server logs (Apache/Nginx, PHP-FPM) are also valuable.
If you instead encounter a blank page, it is useful to follow a dedicated procedure: diagnosis and fixes in case of empty display.
Resolve common causes: plugin, theme, cache, server resources
1) Plugin conflict after update
A plugin can interrupt the update process or cause a fatal error once maintenance is lifted. The most effective test: temporarily deactivate all plugins.
If wp-admin is accessible, do it from the interface. Otherwise, rename the folder wp-content/plugins at plugins_old via FTP. WordPress will deactivate all plugins. If the site returns, restore the folder to its original name, then rename each plugin subfolder one by one to identify the culprit.
2) Broken or incompatible theme
An updated theme can break the front end (PHP error, deprecated functions) or trigger conflicts with the editor. To test, force a default theme (such as Twenty Twenty-Four): if you can access the admin, change the theme. Otherwise, rename the active theme's folder in wp-content/themes ; WordPress will sometimes switch to a default theme if it is present.
3) Cache and optimization: false maintenance
Sometimes a caching system serves a maintenance page even though the site is back. Clear the plugin cache, the server cache (if your host provides one), and the CDN cache. Also remember to clear the browser cache and test in private/incognito mode.
4) PHP limits: memory, max execution time, upload size
Many blocks are caused by limits set too low: memory_limit, max_execution_time, max_input_time. A large plugin update or extracting a zip can exceed these thresholds. Increase them temporarily via the hosting panel, a file php.ini, or your plan's PHP configuration, then re-run updates in a controlled way (one at a time).
Cleanly rerun updates (without risking another blockage)
Once the site is accessible again, the goal is to finish what was interrupted. Proceed methodically:
• Make a full backup (files + database).
• Temporarily disable aggressive optimizations (minification, concatenation, HTML cache) if they have already caused problems.
• Run updates one by one: first the WordPress core, then plugins, then the theme.
• Monitor logs and site behavior after each step.
If you are unsure about the order, backup management, or the checkpoints to verify before/after, a structured approach helps prevent recurrence: method to prevent incidents during changes.
Advanced cases: database, file permissions, and incomplete updates
Sometimes the crash is only the visible part of a deeper problem.
1) Database upgrade message
After a core update, WordPress may request a database upgrade. If this step has not been completed, the admin area can be unstable. Log in to the back office and follow the wizard. If the admin is inaccessible, restore access first (disable plugins, switch to the default theme), then finish the upgrade.
2) Incorrect file permissions
If WordPress cannot write to certain folders (wp-content, plugins, themes, uploads), the update fails. Check permissions and the owner/group, especially if you changed hosting, restored a backup, or used a Git/SSH deployment. A common sign: WordPress repeatedly asks for FTP credentials, or updates fail for no apparent reason.
3) Insufficient disk space
An update requires temporary space. If the disk is nearly full, extraction can stop. Check disk usage, delete old backups, large archives, or oversized caches.
4) Emergency restore
If you have a healthy backup from before the update, restoring may be the quickest option. The important thing afterward is to understand why the update failed (resources, conflict, permissions) so the problem does not recur.
Useful resources to compare troubleshooting approaches
Depending on your level of access (FTP, SSH, control panel), your hosting (shared, VPS, managed) and the context (e-commerce site, high traffic), the steps may vary. To cross-check methods and make sure you haven't missed anything, you can consult:
• detailed guide to fix this type of blockage, useful for a step-by-step approach and variants depending on the case.
• troubleshooting checklist and tips, handy if you want a quick overview of possible causes and solutions.
Discover our offers for WordPress website maintenance
Reduce the risk in the future: best practices before each update
The best fix remains prevention. A few habits drastically reduce the likelihood of a site being locked:
• Update during low-traffic time slots.
• Perform an automatic backup before any update (and verify it can be restored).
• Test in a staging environment when the site is critical.
• Avoid launching 20 updates at once on limited hosting: prefer a gradual rollout.
• Monitor PHP compatibility and the prerequisites of major plugins (builder, e-commerce, security).
• Keep an eye on resources: CPU/RAM, PHP limits, execution time.
Security: don’t turn the outage into an entry point
When a site malfunctions, people tend to multiply quick fixes: disable a protection, open overly broad permissions, leave a temporary folder accessible… These are risky shortcuts. Use the incident to verify that admin access is properly protected (URL, restrictions, server rules, authentication best practices), especially if you exposed debug information or changed settings in a hurry.
If you’re looking for a plugin-free approach to harden the most attacked entry point, here’s a clear method: harden access to the administration interface.
Performance: avoid blind updates that break the experience
A site can come back after removing .maintenance, but still be slowed or unstable: heavier scripts, minification conflicts, a plugin changing behavior, more costly queries. Monitoring performance indicators after intervention helps avoid a second incident (this time on the UX/SEO side): load time, JS errors, visual stability metrics, responsiveness.
To link performance to concrete actions on WordPress, this reading can serve as a guide: benchmarks for performance metrics to track.
After troubleshooting: cleanup and tidy-up (SEO, reliability, consistency)
An emergency intervention sometimes leaves traces: plugins disabled then re-enabled, inconsistent caches, bloated transient tables, multiple revisions, large logs, temporary files. A minimum of housekeeping helps stabilize:
• remove unnecessary temporary files (while being cautious);
• check the integrity of plugins/themes and remove those no longer in use;
• check redirects, the 404 page, and the availability of key pages;
• properly purge caches after stabilization;
• verify that debug mode is disabled once diagnostics are complete.
If you want to take the opportunity to improve the overall cleanliness of the site and limit SEO side effects, you can follow: a visibility-oriented cleanup routine.
When to delegate: critical sites, e-commerce, or lack of technical access
If you don’t have FTP/SFTP access, if hosting is managed with restrictions, if the site processes payments, or if every minute of downtime has commercial impact, it is often more cost-effective to delegate. A maintenance provider can act quickly, secure the perimeter (backups, logs, integrity), fix things without breaking them, and set up a more reliable update plan (staging, monitoring, rollback).
To outsource these recurring tasks and prevent this type of incident from happening again, you can consult: our support packages.
Express checklist (to keep on hand)
• Delete/rename .maintenance at the root.
• Purge caches (plugin, server, CDN, browser).
• If error: enable logs, read debug.log + server logs.
• Disable plugins (rename wp-content/plugins).
• Switch to a default theme if needed.
• Check PHP resources, disk space, file permissions.
• Finish updates cleanly (one at a time).
• Disable WP_DEBUG after resolution.
• Implement prevention: backups, staging, monitoring.
