To fix a site stuck in WordPress maintenance mode, remove the stale .maintenance file from your WordPress installation directory, but only after confirming the update has stopped. Back up first, because an interrupted update may also leave incomplete files that need repair.
For a small business, downtime from that maintenance screen can block enquiries and leave clients wondering whether you’re still available. Start by distinguishing a normal update notice from a failed update, then make one controlled change at a time.
Key takeaways
- Don’t remove
.maintenancewhilst an update is still running. - Use your provider’s File Manager or SFTP to reach the WordPress root folder, and enable hidden files.
- Download the stale file before deleting it, then test the site and dashboard.
- If the screen remains, investigate caches, failed updates and error logs rather than deleting more files.
Is WordPress maintenance mode stuck?
A normal update
WordPress briefly displays a maintenance notice during certain updates. Visitors commonly see: “Briefly unavailable for scheduled maintenance. Check back in a minute.”
That message alone doesn’t mean something has broken. If an update is still progressing, leave it alone. Don’t start another update, remove files or ask another team member to run the same task.
Look at the update screen, update activity and any deployment process your team uses. Establish whether work is still running before intervening.
A notice left after an interrupted update
If the update has failed or stopped, the notice may remain because WordPress didn’t complete its cleanup. A .maintenance file can be left in the installation’s base folder.
However, a provider setting or deliberately enabled maintenance mode can also display a notice. A maintenance plugin such as WP Maintenance Mode, SeedProd or LightStart may show visitors a maintenance page. It can be an “under construction” page or a coming soon page, sometimes with a countdown timer. Some tools display a custom maintenance page. These tools and settings are separate from WordPress’s stale file, so deleting it won’t disable them.
Record the exact message, failure time and last change. Those details help distinguish an interrupted software update from a separate hosting or configuration problem.
Protect the site before editing files
Take a backup of both the website files and database through your account. Include wp-content, wp-config.php and hidden files where present.
Keep the copy outside the live account, and don’t overwrite your last known-good backup. A snapshot of the broken site can preserve useful evidence, but it doesn’t replace a working recovery point.
Next, make sure nobody else is updating or deploying the site. For an agency, this includes colleagues, freelancers and anyone responsible for web hosting.
Write down what you’ll change and keep downloaded copies of affected files. If the account contains several websites, identify the correct domain before opening folders. Editing another installation can create a second outage whilst leaving the original fault untouched.
Find the WordPress root folder
The WordPress root is the folder containing wp-admin, wp-content, wp-includes and usually wp-config.php. WordPress’s maintenance-mode troubleshooting guidance identifies this base folder as the location of .maintenance.
Use your hosting File Manager
Sign in to your provider control panel and open File Manager. Select the folder assigned to the affected domain.
It may be named public_html, www or htdocs. Some accounts put each website in its own subfolder, so use the WordPress folders to identify the installation.
Open File Manager’s settings and enable Show Hidden Files, sometimes called “show dotfiles”. The leading dot makes .maintenance hidden in many file browsers.
Look in the root itself, not inside wp-content. Don’t change permissions or move folders to make the file appear.
If you can’t identify the correct live installation or don’t have access, ask the site administrator or your provider before changing files.
Use SFTP instead
If you prefer a file-transfer application, open an SFTP client such as FileZilla. Enter the server address, username, authentication details and port shown in your hosting account’s connection settings.
Choose SFTP when available. It encrypts the connection, unlike ordinary FTP.
After connecting, browse the remote server’s folders until you find the WordPress installation. Enable hidden files in the client’s display settings if necessary. Your computer’s local files appear separately, so download from the server rather than moving or deleting local copies.
Remove the stale .maintenance file safely
Before deleting anything, confirm that the update has ended or failed. If the update task still shows activity, don’t remove the flag.
Then follow this sequence:
- Find the exact file named
.maintenancein the WordPress root. - Download a copy to your computer.
- Delete only that file from the server.
- Reload the public site in a private browser window, then open
/wp-admin/separately.
WordPress’s Dashboard Updates troubleshooting instructions recommend deleting the leftover file, then running the upgrade again.
However, first establish what failed. If the site now displays a different error, investigate that before restarting the update.
Removing
.maintenanceclears the maintenance flag. It doesn’t repair an incomplete plugin, theme or WordPress update.
Don’t delete similarly named folders, wp-config.php or anything inside wp-content. Also, don’t recreate the stale file as a rollback step. Its purpose was to protect an update that has already stopped.
If the maintenance screen remains
Clear cached copies after the repair
A browser, caching plugin, web server or content delivery network may retain the old screen. Clear each relevant cache layer after removing the underlying cause.
Start with WordPress’s cache controls, then the server cache and CDN cache, including Cloudflare where used. Finally, hard-refresh your browser and test in a private window.
Without dashboard access, use the hosting or CDN controls available to you. Simply renaming a cache plugin’s folder may leave cached pages behind.
If no .maintenance file exists, check whether maintenance mode is still enabled through your host or an installed tool. Avoid deleting unrelated files.
Custom code may also trigger maintenance mode. Ask a developer to inspect functions.php in the active child theme and functions.php in the parent theme. Don’t edit either file during recovery.
Investigate the failed update
A white screen, critical-error message or server error after removal points to another fault. Read the hosting panel’s PHP and web-server logs, matching entries to the failure time.
Contact your provider if you can’t access the logs, the update status is unclear or the evidence points to a server-level fault.
Our WordPress white screen fixes cover blank pages and fatal errors. For an HTTP 500 response, follow our WordPress server error troubleshooting instead.
An interrupted core update may need a controlled file repair. Preserve wp-content and wp-config.php; they contain site-specific content and configuration.
If logs identify a plugin or theme failure, investigate that component rather than changing everything. Don’t increase memory limits, rewrite server rules or make files broadly writable without evidence.
Test recovery beyond the homepage
Recheck the routes customers use
A working homepage doesn’t prove the whole site has recovered. Open important service pages as a visitor and while logged in, test navigation and submit a contact enquiry with clearly marked test details.
Also test the mobile-responsive layout. An update can leave a page accessible whilst breaking a menu or form.
Follow the links used by your Google Business Profile, email marketing and social media campaigns. For lead generation, the destination page and its enquiry process both need to work.
Check that expected confirmation emails arrive and that connected systems and automation receive the submission. This catches faults that a visual inspection misses.
Record the incident and ownership
Note the failed update, error message, affected component and successful repair. Include the relevant software versions and log excerpt, but remove credentials and personal information.
Give one person responsibility for the next update attempt. That avoids overlapping work and makes the outcome easier to trace.
Our guidance on choosing a website support plan explains how maintenance, fault response and recovery responsibilities should fit together.
For agencies needing technical web development and hosting support, See how we collaborate with creative agencies.
Reduce the risk of another interrupted update
Schedule planned maintenance during a quieter period, with a current backup and enough time to investigate failures. WordPress’s official updating instructions also advise taking a backup before upgrading.
For complex sites, test major changes on an isolated staging site first. Restrict access to the staging site for security, and control outgoing integrations so tests don’t trigger real customer communications.
For planned downtime, use a temporary 503 response. It helps search engines recognise the outage as temporary and protects SEO.
Apply WordPress core, plugin and theme changes in controlled stages. Test the front end and essential forms after each stage. Applying everything at once makes it harder to identify the cause of a problem.
If failures recur, inspect server resources and compatibility. Use logs to check for full storage, exhausted memory or server-side timeouts instead of repeating the same failed process.
Website care and maintenance should include monitored changes, off-site backups and recovery testing. Someone must monitor automatic updates, own failed-update alerts and follow through.
Finally, remove temporary diagnostic settings and securely delete logs you no longer need. Keep an incident record so the next person doesn’t repeat unsuccessful changes.
Frequently asked questions
Will deleting .maintenance delete my content?
Deleting only the stale .maintenance file doesn’t delete posts, images or database content. However, it doesn’t reverse damage caused by the interrupted update either.
That’s why you should preserve both files and the database before troubleshooting. Keep the deletion narrow, then test the exact pages and actions that failed.
What does a 503 status code mean?
A 503 response means the server is temporarily unable to handle the request. MDN’s 503 status reference explains the response and its relationship to temporary unavailability.
To inspect a page’s response, open your browser’s developer tools, select Network, then reload the page. Select the main document request and read its status.
A maintenance message is the visible page; the HTTP status is a separate technical response. Inspect both when diagnosing whether service has returned.
Restore service with the smallest safe change
A stale .maintenance file is often a straightforward repair once the update has stopped. Protect the site, locate the correct root folder and remove only the leftover flag.
Then test the customer journey, not merely the homepage. Clear stale caches, resolve any remaining error and record the cause so the next update has a safer recovery path.
