WordPress normally shows a temporary maintenance message while it replaces files during an update. If that message stays visible, first establish whether an update is still running, whether WordPress itself generated the screen, and whether a cache is serving an old response.
For a genuinely stalled core maintenance state, an authorized administrator can remove the specific .maintenance file from the correct WordPress installation after confirming no updater is active and preserving the current site. Then inspect the interrupted update and verify the website. Removing the screen does not prove the update completed correctly.
That distinction matters on a business website. You may recover the homepage while leaving a plugin partly installed, an order process broken, or a second update about to start. This guide walks through recovery and the checks that make it dependable.
Identify which maintenance screen you are seeing
“Briefly unavailable for scheduled maintenance” is the familiar WordPress update message. A branded coming-soon page, a hosting maintenance notice, and a deployment screen may come from different systems.
Record the exact wording and take a screenshot. Note the URL, time, and whether the dashboard is affected. Ask other administrators whether they started an update, a migration, or a deployment. A legitimate maintenance period can look like an outage when the people responsible have not coordinated.
Use a normal visitor session and a separate authenticated session where available. Some maintenance plugins deliberately show the site to administrators while displaying a holding page to everyone else. Conversely, core update maintenance can block administration as well as public requests.
| Observation | Likely place to investigate |
|---|---|
| Standard message appeared during an update | WordPress updater, its maintenance state, and update logs |
| Branded holding page appears only to visitors | Maintenance plugin, theme setting, or hosting feature |
| Browser shows maintenance but origin is healthy | Browser, hosting, or CDN cache |
| File reappears after removal | Another update process or automation |
| Critical error appears after maintenance clears | Incomplete or incompatible update requiring separate diagnosis |
These are starting points, not guaranteed causes. A host may customize the WordPress message, and a plugin may imitate it. Confirm the responsible layer before editing files.
Understand what the .maintenance file does
WordPress can use a file named .maintenance in the installation root to signal temporary update maintenance. The leading dot matters: file managers and SFTP clients may hide the file unless you enable hidden-file visibility.
The WordPress maintenance-mode function reference describes the timestamp-based check and its normal ten-minute freshness window. The presence of a very old file alone is therefore not a complete explanation for an indefinitely visible maintenance page. Cached output, a refreshed timestamp, filters, or a different maintenance system may be involved.
Do not keep changing timestamps to make the screen disappear or remain visible. That interferes with the evidence and can expose a partially updated application. Determine the updater’s actual state first.
Also distinguish .maintenance from a maintenance.php file used to customize maintenance output. Do not delete a similarly named theme or plugin file because a tutorial says to remove “the maintenance file.” The intended target and its location must be clear.
First decide whether an update is still active
A slow update is not necessarily a stalled update. Large packages, limited storage performance, network delays, and post-update migrations can take time. The safe response depends on evidence rather than a universal number of minutes.
Check the dashboard update screen if it remains available. Review the hosting activity log, deployment interface, or maintenance service dashboard. If a managed service owns updates, ask it whether an update job is active before starting a competing operation.
Closing a browser tab does not reliably tell you whether server-side work has stopped. A disconnected browser can leave a request or background process running. Conversely, an update screen can continue displaying an old status after the server job ended.
If you cannot determine the state, contact hosting support with the installation, start time, update target, and visible message. Ask specifically whether a WordPress updater, host-managed update, or deployment is still changing files. “Is my website down?” may get a general availability answer without resolving this question.
Avoid overlapping update attempts
Do not open several tabs and click Update repeatedly. Multiple administrators, automatic updates, a maintenance dashboard, and hosting automation can all become involved. Record which system is responsible and let one process control the operation.
An update lock and a maintenance screen are separate mechanisms. A message that another update is in progress is not automatically resolved by removing .maintenance. Do not delete database lock records based on a generic snippet when you have not confirmed ownership and process state.
If a host needs to stop a hung process, let it use the supported procedure for that environment. Killing arbitrary PHP or database processes can interrupt unrelated requests or transactions on a shared application.
Preserve recovery options before changing files
Confirm a current backup or snapshot and where it is stored. Ideally, preserve both files and database because some updates change application code and stored structures together. The WordPress file-backup guide explains why the site consists of more than exported posts.
When the site is already unstable, preserve the current state as well as the last known good backup. Current files and database may contain recent orders, leads, uploads, or settings that would be lost in a full rollback.
Write down the backup time and time zone. A label such as “today” is not enough for a store that has accepted purchases throughout the day. Identify the gap between the recovery point and the present, and decide how that gap would be reconciled before any database replacement.
You do not need to restore merely to remove a stale maintenance signal. Preserve recovery options first, then choose the smallest justified repair. A full restore is a larger decision with different consequences.
Verify that you are in the right installation
A hosting account can contain production, staging, old migrations, and several domains. The first folder named public_html is not necessarily the installation serving the affected hostname.
Use the hosting site’s document-root information and recognizable configuration to confirm the target. Do not expose database credentials while checking configuration. If WordPress lives in a subdirectory or uses a managed layout, follow the host’s directory map.
Confirm that the path you are viewing is not an old release directory behind a deployment symlink. Editing an inactive release accomplishes nothing; editing a shared directory without understanding the layout can affect several releases.
Keep file access secure. Prefer the hosting file manager over an unsecured public connection, or use SFTP with an authorized account. Remove temporary access when the incident is finished.
Remove a stale core maintenance signal carefully
Use this procedure only after confirming that the relevant updater is no longer active and that the standard WordPress maintenance state is the issue. It describes a general recovery action, not a live test performed on your site.
- Open the correct installation through the host’s file manager or authorized SFTP.
- Enable hidden-file display if needed.
- Locate the exact
.maintenancefile in the WordPress installation root. - Record its modification time and preserve a copy outside the public web directory if it is needed for diagnosis.
- Remove only that file through the supported file-management interface.
- Request the affected page again through a normal visitor session.
- Continue with update verification even if the page now loads.
Do not remove plugin directories, database tables, wp-config.php, or the entire content directory as part of this action. Avoid keeping a renamed copy containing executable PHP in a publicly accessible location. Your private incident record can preserve the relevant timestamp without leaving extra application files exposed.
If the file immediately returns, stop repeating removal. Another process may still be running or starting again. Capture the new timestamp and identify the owner of the process.
What about WP-CLI?
An administrator who already uses WP-CLI can consult the official maintenance-mode command documentation. Confirm the installation path and execution context before using commands that change site state.
The status command can help inspect core maintenance state, but it does not establish whether a host-managed deployment or separate maintenance plugin is active. It also does not validate plugin packages, database migrations, or the public cached response.
Do not install unfamiliar command-line tools during an incident just to follow a shorter tutorial. The hosting interface may provide a safer and more familiar way to remove one confirmed file. Command-line access is useful when the operator understands the environment and can interpret failures.
If the maintenance screen remains after file removal
A persistent screen means the initial explanation was incomplete or another layer still serves the response. Check each layer deliberately instead of repeatedly changing the same file.
Compare cached and current responses
Ask the host whether its cache or a CDN could be serving the old page. Compare an ordinary public request with an approved cache-bypass method. A private browser window changes local cookies and browser state; it does not guarantee a fresh origin response.
Purge the relevant cache through supported controls after confirming the origin application is healthy. A broad purge can increase origin traffic, so be cautious when the server is already overloaded.
Check the actual response status as well as the visible page. A maintenance page may use a temporary failure status, but implementation varies. A successful HTTP status with the wrong content is still a broken customer experience. Conversely, a visually normal cached homepage does not prove dynamic requests are working.
Record whether the stale screen affects all URLs or only a subset. One cached landing page can persist after the underlying application recovers. That narrower problem calls for targeted invalidation rather than a database restore.
Check maintenance plugins and theme settings
Look for an intentionally enabled maintenance or coming-soon feature. Confirm which plugin or hosting tool controls it and whether an expiration schedule is configured. Disable it through the supported interface once the underlying site is ready.
If the dashboard is inaccessible, use vendor or host guidance for that specific feature. Renaming a plugin folder affects every feature the plugin provides, which may include access control or redirects. Understand that impact before using file-level isolation.
A site can have both core update maintenance and a separate holding page. Clearing one does not automatically clear the other. Document which system generated each observed response.
Check hosting and deployment controls
Some hosts place the application behind a maintenance response during migrations, restores, or deployment operations. That state may not use WordPress’s .maintenance file at all.
Review the hosting operation history and ask whether the site is paused, restoring, or waiting for a deployment to complete. Give support the hostname and environment, not just the account name, because production and staging may have different states.
If a managed deployment uses release directories, confirm that its health check completed and that the intended release became active. Manually bypassing the deployment’s holding page may route customers to an incomplete release.
Inspect the interrupted update before calling the site recovered
Once you can reach WordPress, identify what was being updated and whether it completed. Check the target version, installed version, update notices, and relevant logs. A plugin name appearing in the list does not establish that every file was replaced successfully.
Read the changelog and vendor recovery instructions for the affected package. If the update included a database migration, find out whether that step ran and whether it can safely resume. Repeatedly uploading files may not address stored migration state.
The official WordPress upgrade instructions describe supported update procedures and preservation of site-specific content. Use the applicable procedure for core updates rather than treating a core package, a plugin ZIP, and a theme package as interchangeable.
If a premium plugin package is incomplete, obtain a clean copy from the vendor or your legitimate account. Do not use an unofficial download that introduces a separate security risk. Preserve custom changes and establish whether they were made inside vendor files before replacing anything.
Check file integrity when appropriate
For WordPress core, an experienced administrator can use the documented core checksum verification command to compare supported core files with official checksums. The result is scoped to the files and version checked.
Passing a core checksum check does not prove that plugins, themes, uploads, or the database are clean or compatible. A failed check also needs interpretation: identify the differing file, its role, and any documented customization before deciding on replacement.
If unexpected executable files or suspicious modifications appear, stop treating the event as an ordinary interrupted update. Preserve evidence and investigate possible compromise. Installing a fresh core package does not remove every possible persistence mechanism.
Separate incomplete files from incompatibility
A complete update can still fail because a component expects a different PHP version, extension version, or dependency. Compare the installed combination with the vendor’s current requirements.
If a fatal error appears after maintenance clears, capture its exact wording and matching server timestamp. Follow the error toward the affected component rather than deleting the maintenance file again. The maintenance screen and the fatal error are two stages of the same incident, but they need different actions.
A rollback may restore service, but check whether the older package is safe to use and whether database changes prevent a simple file-only reversal. Keep a temporary rollback under review and plan the supported forward fix.
Find out why the update stopped
Recovery without cause review leaves the next maintenance window vulnerable to the same interruption. You do not need an elaborate investigation for every brief hiccup, but recurring failures deserve evidence.
Storage capacity and file-count limits
An update often needs room for the downloaded archive, extracted files, existing files, and temporary working data. A hosting account can hit storage or file-count limits even when the dashboard’s simple disk figure looks acceptable.
Ask the host to check the limits that apply to this installation and its temporary directories. Do not delete backups, logs, or uploads in bulk to create space without understanding retention and recovery needs.
Move obsolete archives to an approved protected destination where appropriate. A ZIP stored in the public site can expose sensitive data, and a backup on the same constrained account may not be an independent recovery copy.
After freeing space through a reviewed cleanup, confirm that the updater can create and replace files. A capacity correction will not repair an already incomplete package unless the update is safely completed or reinstalled.
Ownership and permissions
The application needs appropriate access to its files, but broad world-writable permissions are not a responsible shortcut. Incorrect ownership can cause updates to fail even when directory permissions appear generous.
Use the WordPress file-permissions guidance with the host’s account model. The correct approach depends on how PHP runs and which user owns the installation.
If a recent migration changed ownership, ask the host to correct the affected paths. Avoid recursively applying permissive settings across an account containing backups, private configuration, or other sites.
Document the actual permission issue and the correction. “Changed everything until updates worked” gives the next administrator no way to evaluate the resulting exposure or reproduce the fix safely.
Timeouts, resource limits, and network failures
A download can fail before extraction, extraction can stop, or PHP can terminate while replacing files. The corresponding logs should identify the stage. Ask about the request time, package source, and server event rather than assuming all update failures are memory problems.
An external package host may be temporarily unavailable or reject a license request. Retrying later can be appropriate when the package source is the cause, but repeated retries will not repair a bad credential or incompatible update endpoint.
Do not raise memory or execution limits to arbitrary large values without identifying the failing operation. The hosting plan and process limits may constrain the request regardless of a WordPress configuration change.
Check whether a security service blocked a legitimate package request. A narrow reviewed allowance is preferable to permanently disabling protection. Record the exact destination and reason for any exception.
Competing automation
Hosting updates, WordPress automatic updates, a remote maintenance service, and deployment tools can overlap. Map which system handles core, plugins, and themes, and decide who owns the schedule.
You can keep useful automation while making ownership clear. For example, one service may apply approved plugin updates and another may monitor availability. Problems arise when both assume they should change the same files without coordinating state.
Inspect notifications and job history after an incident. An email saying an update failed may arrive after the site recovers, while another automation retries later. Make sure the final record reflects the actual installed versions and active jobs.
Protect orders, leads, and scheduled work during recovery
A maintenance page does not necessarily stop all data changes. Webhooks, scheduled tasks, API clients, staff interfaces, and external payment systems may continue operating through different paths.
Before a restore, identify which systems can still write data. If transactions must pause, coordinate the pause at the relevant application and integration layers. Keep external payment and fulfillment records available for reconciliation.
WooCommerce’s backup guidance explains the importance of site backups for commerce. For subscriptions, the restore-specific documentation describes additional problems when previously processed work reappears after a rollback.
Do not assume that restoring yesterday’s database reverses yesterday’s payments. External systems retain their own state. A recovery plan must account for missing local orders, changed inventory, renewal actions, and notifications already sent.
If removing a stale maintenance signal restores the site and no data replacement is needed, keep the recovery narrow. Avoid turning a file-state problem into a larger data-reconciliation problem through an unnecessary full restore.
Verify more than the homepage
The recovery is complete only when the affected update and the site’s important functions are checked. Use a short acceptance list tailored to the business.
For a service business, visit the primary service pages, submit a controlled form, confirm delivery, and check the booking path if one exists. Verify the receiving mailbox or CRM rather than relying only on the form’s success message.
For a store, inspect product pages, cart updates, shipping calculations, the relevant payment integration, order creation, and notifications. Use test facilities where possible, and coordinate any live transaction with the owner.
For a membership site, check a permitted user and a user who should be denied. A recovery that exposes protected content is not successful simply because the page loads.
Also check the dashboard, editor, media upload, and any background task involved in the interrupted update. Review matching logs for new errors. Remove temporary diagnostics and verify a normal public session after caches are refreshed.
Check the next scheduled action
Some failures become visible only when the next scheduled job runs. A backup, feed update, scheduled post, or renewal may not execute during an immediate page test.
The WordPress Cron handbook explains that WordPress scheduled work depends on its execution mechanism. If the host uses a system scheduler instead, record that arrangement and confirm it remains active.
Do not run every pending job manually as a generic health check. Some actions send messages, charge renewals, or contact external services. Review the queue and use the relevant component’s supported diagnostic method.
A useful completion record states which delayed functions were observed and which need follow-up. That is more reliable than claiming the whole site was tested after opening two pages.
A practical maintenance incident record
Write a short record while the details are available. Include:
- The first observed time and time zone.
- The exact message and affected hostnames.
- The update target, starting version, and intended version.
- The system or person that initiated the update.
- Whether an active updater was confirmed or ruled out.
- The backup or snapshot identifiers preserved.
- The exact file or setting changed during recovery.
- The installed version and package status afterward.
- The functions tested and any unresolved checks.
- The likely cause, evidence, and prevention owner.
Keep secrets out of this record. Store access instructions in your approved password manager rather than embedding credentials in a document shared with several contractors.
If the cause remains unknown, say so. A factual record of what restored service is still valuable. Inventing a confident cause can lead the next maintainer to ignore the actual recurring failure.
Manage the customer experience while recovery continues
A technical maintenance message rarely tells a customer what to do next. If recovery will extend beyond a short update window, coordinate an accurate holding message through the system that owns maintenance. Include an alternative contact route only if someone is actually monitoring it.
Avoid promising a reopening time before the cause is understood. An honest statement that online booking is temporarily unavailable, paired with a working phone number, can be more useful than a countdown that repeatedly reaches zero. Make sure the contact route does not depend on the same broken application.
For a store, tell staff how to handle customers who report that payment appeared to succeed while the website did not confirm an order. Check the payment provider and local order records before asking the customer to pay again. A failed browser response does not establish that an external payment failed.
Keep marketing activity in view. If paid campaigns send visitors into a prolonged maintenance screen, the business may choose to pause affected campaigns through its normal owner. The website maintainer should communicate the condition and expected next update, rather than silently changing unrelated business systems.
A public status message and an internal incident record serve different audiences. Customers need a clear alternative and a trustworthy update. The technical team needs timestamps, versions, logs, and recovery state. Keep private infrastructure details out of the public message.
Treat search behavior as a separate check
A brief maintenance event does not justify redesigning the site’s indexing controls. Do not add a site-wide noindex directive, change canonical URLs, or block every crawler as an improvised response to a stalled plugin update. Those settings can remain after recovery and create a second problem.
If a hosting or maintenance tool controls the response status, have a qualified administrator confirm that its temporary response behaves as intended. Google explains the consequences of unsuccessful responses in its HTTP status and network errors documentation. That guidance does not provide a guaranteed duration after which rankings change, so avoid making such promises.
After recovery, check representative public URLs for the intended content and response. Inspect any temporary indexing or redirect setting introduced during the incident and restore the intended production configuration. A correct maintenance exit includes removing emergency changes that could continue affecting discovery.
Hand off an unresolved incident without losing the evidence
Sometimes the business owner cannot determine whether an update is active or which maintenance layer controls the screen. At that point, a precise handoff is more productive than trying increasingly broad fixes.
Send the host the affected hostname, environment, first observed time with time zone, update target if known, and the exact message. State whether the file exists, whether its timestamp changes, and whether the behavior differs between public and administrator requests. Do not send the contents of configuration files containing credentials.
Ask for specific findings: whether a process is still changing files, whether a host maintenance control is active, whether storage or ownership blocked the update, and where the matching error was recorded. Request that the response distinguish a confirmed cause from a possible cause.
If the host restores service, ask which operation changed the site and which versions are now installed. “We fixed it” is not enough information for later compatibility review. Confirm whether a database restore occurred and, if so, the recovery point and potential data gap.
For a plugin vendor, provide the package version, legitimate download source, related dependency versions, and the stage where installation stopped. A vendor can investigate an extraction or migration failure more effectively when it has that context rather than only a screenshot of the maintenance page.
Keep one person responsible for coordinating the incident. Multiple parties making simultaneous file changes can erase the relationship between action and outcome. The coordinator should record each proposed change, preserve the current recovery point, and arrange the final customer-function tests.
When the site returns, close the loop with the business owner. State what works, what remains untested, what caused the interruption if known, and who will complete any follow-up. That final operational handoff prevents an apparently recovered site from being left with a hidden update failure.
Three illustrative recovery situations
These examples describe possible decision paths. They are not customer cases or test results.
A core update stops and the standard message remains
An administrator records the update time and asks the host to confirm that the updater ended. After preserving the current site, the administrator removes the confirmed core maintenance signal from the correct root.
The site then loads, but core files require verification. The administrator completes the supported update process, checks the installed version, and tests the dashboard and lead form. The incident record distinguishes removal of the maintenance screen from completion of the update.
A branded page remains but no core maintenance file is active
The owner finds that administrators can see the site while visitors see a branded holding page. The hosting update history shows no active update. Investigation identifies an intentionally enabled maintenance feature.
The team verifies that the underlying site is ready, disables the feature through its supported control, and clears the relevant cached response. No database restore or core-file replacement is necessary.
The maintenance file keeps returning
A file is removed after an apparent stall, but a new timestamp appears. The team stops removing it and checks job history. A remote maintenance system is retrying an update that fails because its package download cannot complete.
The package-access problem is corrected through the vendor’s legitimate licensing process. One update owner completes the operation, and the team reviews the overlapping schedule so another system does not immediately repeat the same work.
Keep recovery access available
Check that the business can reach the hosting panel and backup destination without relying on a password-reset email generated by the broken website. Recovery access should use accounts controlled by the business and protected through its normal account-security process.
Store the document-root location, support contact, and backup instructions where an authorized substitute maintainer can find them. The record should explain how to identify production versus staging and who can authorize a restore. Keep credentials in the password manager rather than in the instructions themselves. A technically simple file correction can still become a long outage when nobody knows which account controls the installation or whether the only available backup is usable.
Prevent the next stalled maintenance window
Plan updates as small changes with recovery and verification. Keep storage headroom, supported runtime versions, valid package access, and clear ownership. Read release notes for critical components and test significant changes on a protected copy.
Choose a business-appropriate window, but do not use a quiet window as a substitute for backups. Low traffic does not mean no transactions. Record the expected update duration and who will investigate if it does not complete normally.
Keep update notifications going to a monitored address. An alert sent to a former contractor is not an operational process. Ensure the business can access hosting and backups if the primary maintainer is unavailable.
After each material update, run the same short business-function checks. Over time, improve the list based on actual incidents rather than adding dozens of generic checks nobody performs.
Frequently asked questions
Is deleting .maintenance always safe?
No. First confirm the correct installation, preserve recovery options, and establish that an updater is no longer changing files. Removing a core maintenance signal during an active update can expose a partially updated application. A separate maintenance system may require a different procedure.
Why do I still see maintenance after more than ten minutes?
WordPress’s normal core check considers the maintenance timestamp, so an indefinitely visible screen needs more investigation. A cache may retain an old response, another process may refresh the state, or a plugin or host may generate the screen. File age alone is not a full diagnosis.
Will removing the file delete posts or orders?
Removing the specific core maintenance signal does not itself restore or overwrite the database. However, the interrupted update may have other consequences. Preserve the current site and verify its important functions before declaring recovery complete.
Should I restore a backup immediately?
Usually, first identify the responsible maintenance layer and interrupted operation. A restore is appropriate when evidence supports it, but it can overwrite newer records. A narrow file-state correction may be sufficient, while an incomplete or incompatible update may need a supported reinstall or carefully planned rollback.
Can I fix this without dashboard access?
Often the hosting file manager or authorized SFTP provides the necessary access. Hosting support can also inspect active update processes and managed maintenance controls. Confirm the correct installation and avoid sharing credentials in public support posts.
Why does the problem happen during every update?
Recurring failures suggest an underlying issue such as capacity, ownership, package access, resource limits, or competing automation. Gather matching logs and job history. Repeatedly removing the maintenance signal without addressing the failed stage leaves the cause in place.
Does a working homepage mean the update succeeded?
No. The homepage may be cached, and a partially installed component may fail only during a specific action. Check the installed package, relevant logs, administration, and the customer function affected by the update.
Can automatic updates still be useful?
Yes. Choose automation according to site complexity, monitoring, recovery capability, and responsibility. The goal is a controlled update process with clear ownership and verification. Disabling every update indefinitely creates a different maintenance problem.
Recover the site and close the incident properly
A maintenance screen is useful protection while an update changes files. Recovery means understanding why that protection remains, clearing the correct state when appropriate, and confirming that the application behind it is ready for customers.
Web Expert Solutions provides WordPress update recovery, troubleshooting, and ongoing maintenance. If a stalled update keeps returning or leaves important functions broken, share the update history, affected workflow, and available backup details so the repair can preserve current business data and address the underlying failure.
