Use WordPress maintenance mode as a controlled service interruption: record the state, check the public HTTP response, preserve an authorised recovery route and verify normal service afterwards. A maintenance message on screen is only one part of the check. The status code, affected URLs and customer journeys also need explicit acceptance criteria.
Start with the reason for the interruption. Replacing a shared template, recovering a failed update and temporarily restricting a checkout are different jobs. Write down which service must stop and which contact route should remain useful. That makes it possible to choose a method and judge its actual effect rather than enabling a plugin because it has an attractive holding page.
What does core maintenance mode actually do?
WordPress marks wp_maintenance() as private core functionality. The core reference is useful for understanding behaviour, but this private function is not a public integration point to paste into a theme. The core function returns immediately when maintenance mode is disabled. That establishes a basic distinction between a maintenance state and ordinary page execution.
The default maintenance message can be replaced with a wp-content/maintenance.php drop-in. The displayed core implementation loads a maintenance.php drop-in and then stops execution when that file exists. A custom page therefore needs its own careful review; do not assume that replacing the message automatically preserves every response detail of the default branch.
The default core maintenance response sets Retry-After to 600. The default core maintenance message uses an HTTP 503 response. These are properties visible in the documented implementation, not a promise about a plugin, proxy or customised drop-in on a particular site. Inspect the response delivered by the actual public URL before recording the intended behaviour as achieved.
A browser can show similar wording for responses that differ technically. Save both the response headers and a screenshot. The former records the machine-visible result; the latter records whether a person can understand what has happened and what to do next. Neither one replaces the other.
How should activation, access and recovery be separated?
WP-CLI provides a maintenance-mode activate command. WP-CLI provides a maintenance-mode deactivate command. Both are documented under the maintenance-mode command group. Before an authorised operator uses either, confirm the intended WordPress installation and the execution account. A command without the correct site context is an unsafe operating instruction on a server hosting several sites.
WP-CLI provides a maintenance-mode status command for displaying the current state. WP-CLI provides a maintenance-mode is-active command for detecting the state. Use a human-readable status check for the change record and an appropriately tested state check when designing automation. Establish the command’s behaviour in the target environment before making a script depend on it.
These commands describe maintenance-state control. They do not establish that a particular visitor, editor, integration or administrator can bypass the public response. Define the required access route separately, then test it using the relevant account and an unauthenticated session. An open administrator browser tab is weak evidence of what a new visitor sees.
| Check | Intended observation | Evidence to retain |
|---|---|---|
| State before work | Normal state understood | Site identifier and status output |
| Maintenance response | Intended interruption visible | Public URL, headers and screenshot |
| Operator access | Authorised recovery remains possible | Tested route and responsible operator |
| Custom holding page | Clear wording and suitable response | Direct request to the customised result |
| Return to service | Normal content and journeys restored | Fresh public checks and completed task |
| Exception | A failure can be escalated | Named owner and stop condition |
Assign one operator to state changes and another person, where practical, to review the customer-facing result. The point is an explicit division of tasks, not a requirement to enlarge a small business’s team. If one person performs both roles, record both checks rather than treating activation as proof of success.
What belongs in the original interruption card?
Consider this hypothetical maintenance window for a course-enquiry site. The planned task is a shared header replacement. The original interruption card contains six fields: service being interrupted, intended public response, operator route, verification URLs, recovery action and reopening evidence. Fill it in before touching the live environment.
Define the service boundary. List the homepage, a course page, the enquiry form and the enquiry confirmation. Decide whether all four should show the maintenance response during the work. If the requirement differs by URL, have the chosen implementation demonstrate that distinction in a test copy instead of assuming core mode provides selective access.
Name the recovery route. Identify the authorised operator and how that operator will reach the installation if the public site cannot be used. Confirm the correct site path and the approved recovery procedure. Keep credentials out of the card. The useful record is the responsibility and tested route, not a copied password or access token.
Specify the holding message. Write a concise explanation, a suitable next step and a contact method that somebody actually monitors. Avoid promising a reopening time that has not been agreed. Have the content owner read the page on a phone to check that the key instruction is visible without scrolling past decorative material.
Record two observations during interruption. First, request the selected URLs without a logged-in session and save their response details. Second, check the page visually and follow its contact link. If a custom response differs from the intended status or blocks the operator’s recovery route, stop and resolve that exception before proceeding with the unrelated header work.
Reopen deliberately. After the approved work, deactivate the maintenance state through the chosen method. Request the same URLs again and compare the result with the recorded baseline. The card is incomplete until the operator has checked a fresh visitor session, rather than merely observing the success message from the deactivation command.
Which return-to-service tests matter most?
Check the task a customer came to complete. On the course site, that means reading a course, reaching the enquiry form, submitting an authorised test and seeing the intended confirmation. Keep the test identity recognisable and follow the site’s agreed process for handling the record. A restored homepage does not establish that every important journey has recovered.
Inspect navigation, images and essential forms after the interruption. If a cache or delivery layer is part of the installation, include it in the investigation when public responses disagree with the application state. Record what was observed before changing multiple layers at once; otherwise, the cause of an inconsistent result becomes hard to identify.
Use the website maintenance scope guide to assign the broader care responsibilities. For access and incident preparation, see WordPress security. Maintenance mode is a narrow operating state within that wider work, not proof that the site is secure or that a failed change has been repaired.
Keep the completed card with the change record: what stopped, what changed, what reopened and who checked it. For a wider WordPress brief, use WordPress services and get started with the affected journey and the recovery questions still needing an answer.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.