WordPress stuck in maintenance mode: restore the site without a plugin

Check what the maintenance page means

You started an update, and the site now displays a message saying it is unavailable for maintenance. A few minutes later, the page is still there. Before deleting a file, distinguish two situations: an update is still running, or an interrupted operation has left the site in an inconsistent state. Removing the message is not enough to prove that all files were installed correctly.

WordPress’s native mode uses a file named .maintenance in the installation’s main directory. The leading dot matters. This file contains a time marker used during the update. It does not contain your posts and is not a site backup. Plugins and hosts, however, offer their own maintenance pages, which do not always depend on this file.

Start by recording the displayed text and the time when the update began. Look for the host’s branding, a countdown, or a design you previously configured. These are clues to its origin, but not sufficient proof: the native page can also be customized.

This guide mainly concerns a WordPress installation whose hosting you can inspect. On a managed plan without file access, use the procedure offered in the customer account or ask support to carry out the corresponding step.

Choose your approach and avoid simultaneous actions

If the update is confirmed complete or interrupted and a native marker remains, follow approach 1 using the file manager. If you already use SSH and WP-CLI, approach 2 performs the same intervention with an explicit command. If native maintenance mode is inactive but the page remains, move to approach 3 to identify maintenance managed elsewhere or a cached response.

These routes are alternatives, not three operations to perform systematically. Do not run several repairs in parallel. One person could remove the marker while another is restoring files, exposing an incomplete installation to visitors. Notify the other administrators and agree on one person responsible for the intervention.

Keep the tab that started the update open if it still exists. Record its last message without clicking the update button again. Closing the browser does not guarantee that server-side processing has stopped; a frozen screen does not guarantee that it is continuing either. The host’s log or update-management tool can often settle the question.

For a store, also record the last known order before the incident. That information will be useful if you consider a restore. The goal is to return the site to a consistent state without losing data received since the last backup.

Wait for the operation to actually finish before intervening

A brief maintenance period during an update is normal. Check the administration screen or hosting panel to see whether the operation is progressing, has finished, or has failed. Do not infer its state solely from the number of seconds that have elapsed in your browser.

In its native behavior, WordPress no longer treats the marker in .maintenance as active once it is at least ten minutes old. This interval refers to the value stored inside the file, not simply the time displayed in the file manager. There is therefore no guarantee that any maintenance page will disappear ten minutes after your first visit.

If the message persists, successive operations may be recreating the file, another layer may be displaying its own maintenance page, or an old response may be cached. An incorrect server clock also warrants checking when observed dates are inconsistent. Avoid deleting the same file every minute without identifying what recreates it.

If you have no way to tell whether installation is still underway, ask the host to check the process. Provide the domain, start time, and component being updated. This specific check is preferable to requesting a general site reset.

Prepare a copy of the current state

Before continuing, locate a full backup and its date. Check that it contains files and the database. An export of posts alone cannot reconstruct a site’s themes, plugins, media, and settings. If the healthy backup is old, also retain the current state so you do not lose additions made since then.

The hosting panel may offer a snapshot or a restore to a separate copy. Use that option where available. A backup made during an unfinished update can capture files from several versions: it preserves the observed state but must not be called a healthy backup without checking it.

Record the component being updated, its previous version if known, and the intended version. Retain error messages about downloading, extraction, storage, or writing. This information guides the repair after the maintenance message has been removed.

Do not immediately roll the entire database back to yesterday. On an active site, that operation may erase recent orders or registrations. A full restore is appropriate only when its consequences are understood and the data that must be preserved has been handled.

Approach 1: remove the native marker through file access

Open the hosting account’s file manager or your usual SFTP connection. Select the affected domain and correct directory. Look for the wp-admin, wp-includes, and wp-content folders to identify the installation. If several copies exist, check the path in the domain configuration before touching anything.

Enable hidden files. The file you want is named exactly .maintenance and sits at the WordPress root. Do not confuse it with a folder named maintenance, an HTML page, or maintenance.php inside wp-content. They do not serve the same purpose.

Once the update operation is confirmed stopped, download a local copy of the marker as a record, then remove only that .maintenance file from the server. Use the file manager’s targeted action: there is no reason to delete an entire folder or every file whose name contains maintenance.

Reload administration, then a public page. If the site returns, proceed to the file and feature checks below. If a critical error replaces maintenance, you have uncovered a second failure: the installation probably needs further repair. Do not arbitrarily recreate the marker to hide the error and declare the operation complete.

If the file is absent, the deletion suggested by many tutorials does not apply to what you are seeing. Move to approach 3. If it reappears immediately, record its time and have the task creating it investigated before trying again.

Approach 2: use WP-CLI on the correct installation

This alternative suits people with an authorized SSH session and WP-CLI already installed. It avoids manipulating the file by hand. The same prerequisites apply: no update may still be writing to the installation.

Change to the relevant WordPress directory. Check the associated path and domain in the hosting panel, especially if the account contains several sites. First request maintenance mode status using the read-only command below. Run deactivation only after confirming that the marker can be removed, then request the status again.

WP-CLI reports on the native mechanism. An inactive status does not prove that a CDN, hosting, or plugin maintenance page has been removed. Open a public URL after the command. If the terminal reports a file-access error, have the owner or permissions of the exact path corrected instead of defaulting to excessive privileges.

The following three lines show the command order. Read each result before running the next command; do not paste them as an automatic repair without checking the context.

wp maintenance-mode status
wp maintenance-mode deactivate
wp maintenance-mode status

Approach 3: find maintenance managed elsewhere

If the native marker is absent or inactive, open the hosting panel. Look for a maintenance function, an ongoing deployment, or an announced intervention. Some services display a page in front of WordPress: changing WordPress files will not affect that result. Record the name of the active function before changing it.

In WordPress administration, then inspect tools you already use to display a holding page. A maintenance plugin may let administrators browse the site while showing a different screen to visitors. If so, open its settings and disable maintenance mode when the site is ready. You do not need to delete the plugin to test this setting.

Do not confuse this maintenance with access protection deliberately applied to staging. Removing authentication or making a private copy public is not an update repair. Check the domain, environment, and intention before changing visibility settings.

Finally, compare responses in your signed-in session and a private browsing window. If the host confirms maintenance is over but some visitors still see the page, purge the corresponding cache using the tool already used by the site. Target the relevant page or CDN cache, then test again. Clearing a browser cache does not, by itself, purge the server cache.

Check whether the update left incomplete files

The site opens again: take a few minutes to check what was actually installed. Under Dashboard → Updates, record the state of the affected core, theme, and plugins. Compare it with the operation you started. A displayed version number does not guarantee that every package file is present, but it helps identify an obvious discrepancy.

If the initial message reported a failed extraction or copy, do not immediately restart the same batch of updates. First investigate the cause in logs or the hosting panel. Another attempt on full storage is likely to fail at the same point and complicate diagnosis.

When a specific plugin is incomplete, restoring a compatible official package may be necessary. Preserve its configuration and data; the Delete action in administration can trigger uninstallation. Also check whether the component contains local customizations. A commercial plugin should come from the publisher’s account, not an archive found on an arbitrary download site.

For WordPress core, follow a replacement procedure appropriate to the intended version. Core folders and user files serve different purposes. Do not blindly replace wp-content, which contains themes, plugins, and media, or wp-config.php, which contains the installation configuration. If you are uncomfortable with these distinctions, have the host perform the repair using your record of the incident.

An additional core-file check with WP-CLI

WP-CLI users can compare core files against the checksums published for WordPress. This check can identify a missing or different file after an interrupted copy. It repairs nothing automatically and is not a complete check of every site component.

Run the command below from the correct installation. If you need to specify a version or language, use those actually expected for your package. Comparing a French installation with a different reference may produce discrepancies that require interpretation. Keep useful output for support without publishing private paths or account information.

A successful check does not prove that the database, plugins, themes, and customer orders are all healthy. A failed check does not, by itself, prove an intrusion. It identifies differences that need examination in context. Do not bypass a certificate problem by disabling TLS verification to finish this test: have the connection corrected or use another reliable verification procedure.

wp core verify-checksums

Fix the cause before restarting an update

Insufficient space is a cause to check concretely. The server may need room to download an archive, extract it, and temporarily retain several sets of files. Check used space and, where the panel displays it, the file-count quota. An account can hit its file-count limit without using its entire volume in gigabytes.

Do not free space by randomly deleting media or your only backup. Identify temporary files confirmed by the host and copies already archived elsewhere. If you do not know what can be removed, request a report of the largest directories and a targeted intervention. Retain a usable restore point throughout the operation.

File permissions and ownership can also prevent writing. A manual upload made with another account may produce mixed ownership. Ask which process should write to the affected folder and have that path adjusted specifically. Applying 777 to the entire installation broadens permissions without guaranteeing that the update will work.

If downloading fails, check communication with the official service and any hosting incidents. If an execution limit regularly stops the operation, have the provider examine the process. Raising every limit blindly does not distinguish a large archive, slow storage, and a faulty component.

Once you identify the cause, restart one component and observe its result. Then test the site before proceeding to the next. This method requires more attention than restarting everything, but it lets you identify which step succeeds or reproduces the incident.

Handle similar-looking messages as separate failures

The message “Another update is currently in progress” concerns a mechanism separate from .maintenance. Removing this file is therefore not a universal solution to that lock. Check whether a task is still active and let it finish. If the lock persists after a confirmed failure, have the host inspect its state before changing database values.

Likewise, a critical error appearing at the end of maintenance requires examining PHP logs, versions, and loaded components. A blank page or 500 error is not fixed by removing the marker again. The critical-error guide explains recovery routes and how to isolate a faulty component.

On a store, an update may also start background data processing. The public page may return while that processing continues. Consult the relevant component’s notices and avoid another restore while it is working. If you must interrupt or resume that process, request a procedure suited to its version and the current data state.

Reopen the site after a complete check

First test the home page, a post, and administration. Then add the functions important to your activity: search, login, a form, cart, or checkout in test mode. One page returning is not enough if the updated plugin manages a feature absent from that page.

Check the experience of a signed-out visitor. If you use the browser’s network tools, inspect the status of the main response: native maintenance uses a temporary 503 response, while a normal page should return an appropriate success response again. An old maintenance page may appear to disappear visually while still leaving an incorrect response at some addresses.

Keep a brief record: the operation that caused the incident, cause identified, correction applied, final versions, and pages tested. Clearly flag features you could not verify. For example, observing that the cart displays is not equivalent to testing a payment notification end to end.

For the next update, prepare the backup, check available space, and choose a time when you can verify the outcome. Use a test copy for sensitive changes. The incident is no reason to abandon security updates indefinitely: make their execution more reliable and know how to roll back when an incompatibility appears.

Should you install a plugin to exit maintenance mode?

In this particular situation, adding a plugin is rarely useful. If WordPress stops before loading its components, the new tool cannot resolve the problem. Files, the hosting panel, and optionally WP-CLI already provide the means needed to diagnose and remove the native marker.

A maintenance plugin may later help you prepare a custom holding page for planned work. That need is different from repairing a failed update. Choose one only if its features are useful to you, then check how it activates, who can bypass the page, and how it deactivates. It should not become a screen that indefinitely hides an unresolved failure.

If you request assistance, send the domain, last update message, time, marker status, and checks already performed. State whether recent orders must be preserved. With those details, support can address the likely cause without repeating every operation or immediately proposing a full restore.

Interpret a checksum check after maintenance

A checksum check produces three situations that require different responses. If it succeeds, you have compared core files against a reference; continue checking plugins and features because that result does not cover them. If it reports a different or missing file, retain the precise filename and have it compared with the official package for the expected version and language. Do not automatically delete every reported file.

If the command fails because the reference cannot be downloaded, no complete comparison has taken place. That is neither proof of corrupted files nor a reassuring result. Have communication with the official service restored, then repeat the check once. Keep TLS verification enabled.

The core check runs before WordPress loads normally, making it useful when a component prevents administration from opening. It still depends on file and network access. A maintenance plugin does not extend this check: its purpose is to display a holding page. In your report, distinguish “core compared,” “plugin restored,” and “functionality verified” instead of summarizing everything as “site repaired.”