Website under maintenance

What under maintenance means

A site marked under maintenance has been deliberately taken offline, usually for a planned task such as a deploy, a redesign, a content load, or a server move. The correct protocol result is HTTP 503 Service Unavailable with a short page that says when the site will be back. The Retry-After header on that 503 tells browsers and crawlers how long to wait, which protects the URLs from being dropped.

The failure mode is not the page itself. It is the marker left behind after the work finishes, or the placeholder served with a 200 instead of a 503, which makes search engines treat a "back soon" stub as the real page.

Check the marker

Maintenance is normally a small switchable artifact, not the code of the site. The usual suspects:

• A .maintenance file in the site root, which WordPress creates during an update. When it is left behind, the whole site serves the maintenance screen.
• A maintenance mode toggle in the host panel or a plugin. In most site builders the maintenance toggle lives in the Site Settings or Build/Maintenance area; note where your builder keeps it so you can turn it on and off without hunting.
• A deploy script that dropped a marker file and never removed it after the job.

The check order:

1. Load the page and read the exact text. If the message names the actual host or account, someone turned a mode on.
2. Look at the response status in the developer tools Network tab. A 503 with maintenance text is maintenance; a 503 with an empty body, or a 500, is normally something else, such as overload or a dead database.
3. Find the marker. In WordPress that is the .maintenance file in the site root; in cPanel it is a visible maintenance toggle.
4. Check the deploy history. A marker that "arrived" with the last build and never went away is the classic cause.

What is too long

A maintenance window should last as long as the planned work, and no longer. A page that has shown maintenance for days, with no deploy in the history, is really one of two things: the work finished and someone forgot to end the mode, or the site is down and the maintenance screen is covering a real outage.

The TTL of the marker matters. If you flip the switch off but the Retry-After header asked for 60 minutes, that cached 503 can make the site look down to a visitor for up to an hour. Remove the header or keep its value accurate when the work is done.

The steps to bring it back

1. Confirm the marker still exists: the .maintenance file, the plugin toggle, or the platform monitoring dashboard.
2. Turn it off. For WordPress that means deleting the .maintenance file; for a plugin that is toggling the mode back on, or for a host that is a panel switch.
3. Reload in a private window and prove the real page appears. Do not trust a regular tab, the browser keeps its own cache.
4. Check with a command: curl -sI https://example.com/. The status must be 200 and there must be no Retry-After in the response.
5. Clear the layers that can still hold the old 503: the page cache, the CDN cache, and the local browser cache with a hard reload.
6. Remove the announcement only after the site has returned successful pages for a few minutes.

Prevention

• Automate the switch. A deploy script drops the marker, and a post-deploy step removes it and verifies the home page returns 200 before the deploy is reported done.
• Bind the maintenance mode to a single flag per site, so "on for five minutes for a deploy" cannot orphan a stale marker.
• Set a monitoring alert on "503 for more than the scheduled window" instead of only "site down".
• When a maintenance page appears with no planned work at all, treat the host dashboard or an automated tool as the source and verify the marker there, not just in the browser.