It Is Temporarily Unavailable Due to Maintenance: What the Message Means and How to Do It Right

It is temporarily unavailable due to maintenance means the server just answered with an HTTP 503, and often a Retry-After header telling the browser when to check again. Nothing about your account is broken. As a visitor, the site, app, or plugin behind it is mid-update and will be back within minutes or hours. As a site owner, the same message is a tool you control: return 503 instead of 200, set Retry-After honestly, and keep the update short, and neither users nor search engines mistake the window for the site going away.

Search this exact phrase and two audiences collide: people staring at someone else’s maintenance screen wondering if their account died, and site owners whose own WordPress update script stalled mid-run. Most guides answer only one side. The message is not a failure the way a 404 or 500 is; it is supposed to happen, briefly, and the gap between a maintenance window that helps you and one that quietly de-indexes your homepage comes down to a handful of HTTP details almost nobody explains.

Table of contents

• What the message means as a visitor
• Why WordPress shows this specifically, and how to clear it
• Building a maintenance page that does not cost you rankings
• Doing it on nginx, a static host, or a platform
• How long is too long
• When it is not actually maintenance
• How this fits the rest of the stack
• FAQ

What the message means as a visitor

The wording varies — briefly unavailable for scheduled maintenance, temporarily unavailable due to maintenance, service unavailable — but the mechanism is the same. The server is deliberately returning HTTP 503, which tells the browser and any crawler that the outage is planned and temporary, as opposed to 500 (something broke) or 404 (nothing is there).

A well-built maintenance response includes a Retry-After header, either a number of seconds or a specific timestamp, so the client knows when to try again instead of guessing. Browsers rarely surface that header to a human, but search engine crawlers read it closely, which is the entire reason it matters.

• A host or app deploy in progress. The most common cause: a platform is rolling out an update and briefly serves 503 to everyone until the new version is live.
• A CMS mid-update. WordPress in particular writes a lock file the moment an update starts and removes it when the update finishes; if it never finishes, the lock file stays.
• A CDN or load balancer with no healthy backend. The edge is up, the origin is not, and the edge is technically telling the truth.

Why WordPress shows this specifically, and how to clear it

WordPress creates a file named .maintenance in the site root the instant a core or plugin update begins, and deletes it the instant the update finishes cleanly. If the update is interrupted — a timeout, a memory limit, a lost connection — the file survives and the site serves the maintenance screen indefinitely, which is why this specific error is disproportionately a WordPress complaint rather than a generic hosting one.

1. Connect over SFTP or the dashboard’s file manager and look in the site root for a file called .maintenance.
2. Open it. If it just sets a timestamp variable, delete the file.
3. Reload the site. If it loads, the update actually finished and only the lock file was left behind.
4. If the site errors instead of loading, the update itself failed partway; check the plugin or core version and re-run the update rather than repeatedly deleting the lock file.

Raising the PHP memory limit and disabling any update-blocking security plugin during the update usually prevents the timeout that caused this in the first place.

Building a maintenance page that does not cost you rankings

The mistake that shows up constantly: a maintenance page that returns HTTP 200. To a crawler, a 200 status means this is the real content of the page now, so a generic ‘we will be back soon’ message with a 200 status can get indexed as the actual page, replacing your real rankings with a placeholder.

• Return 503, always. Every response during the window, including the homepage and any URL a bot might hit, should carry the 503 status.
• Set Retry-After. A number of seconds for a short window, an HTTP date for a longer one. Crawlers back off and recheck instead of treating the outage as permanent.
• Keep the maintenance page itself fast. A 503 that takes eight seconds to render is still a slow 503.

A short 503 window does not damage rankings on its own; a window stretched over days, or one serving 200 by mistake, is what causes the damage. The maintenance page guide covers the markup in more detail.

Doing it on nginx, a static host, or a platform

The pattern is the same everywhere: intercept every request, serve a small page, and force the status code.

location / {
    if (-f /var/www/example.com/maintenance.flag) {
        return 503;
    }
    try_files $uri $uri/ =404;
}

error_page 503 /maintenance.html;
location = /maintenance.html {
    internal;
    add_header Retry-After 3600;
}

Drop maintenance.flag onto the server to turn it on, remove it to turn it off, and nginx returns 503 with the header set on every request in between.

On a static host with no server to configure, the honest options are a build-time swap of the deployed index page for a maintenance version, or a status page hosted elsewhere with DNS temporarily pointed at it. Neither is as clean as a 503 from your own server, so keep the swap short and revert it as soon as the real update is done.

How long is too long

A window measured in minutes is invisible to almost everyone. One measured in hours starts showing up in monitoring alerts and support tickets. One measured in days starts showing up in search results, because crawlers eventually stop respecting Retry-After and re-crawl on their own schedule, at which point a stale placeholder page can get indexed.

• Under 10 minutes. Normal, no communication needed beyond the 503 itself.
• Under 2 hours. Post the window somewhere visible — a status page, a pinned social post — if the site has ongoing traffic.
• Longer than that. It is not really brief maintenance anymore. Treat it as an incident: a specific reason, a specific estimate, and updates if the estimate slips.

If updates regularly take longer than a coffee break, the fix is usually to stop updating in place — build a new version alongside the live one and switch over, rather than taking the live site down while the update runs.

When it is not actually maintenance

The message sometimes covers for something else: a host that rate-limited the origin and is serving a generic 503, a firewall blocking a crawler or a specific region, or a genuine outage dressed up as scheduled maintenance to buy time. curl -I on the URL shows the real headers — a Retry-After that never gets shorter across several checks is a sign the outage is not actually planned.

Compare that against a scheduled window you set yourself: you know the Retry-After value because you wrote it, and it counts down predictably. An open-ended 503 that has said try again in 3600 seconds for six hours straight is not maintenance, it is an outage using maintenance’s status code. If the site is unreachable rather than showing any message at all, the problem is upstream of the application — DNS, the load balancer, or the network path — and no maintenance page can appear because nothing is answering to serve one.

How this fits the rest of the stack

A maintenance window is only ever as risky as the status code behind it: get the 503 and Retry-After right and a two-minute deploy stays invisible to search and mostly invisible to visitors. The harder version of this problem is avoiding the window altogether — deploying a new build alongside the live one and switching traffic over instead of taking the site down to update it. Static sites on RunxBuild build from the repository and swap in the new version without a maintenance screen in between. If you are weighing a static rebuild against a service that needs a real deploy pipeline, the RunxBuild hosting calculator puts both options next to the numbers, and the dashboard shows the build log for every deploy.

Useful related references:

• Briefly Unavailable for Scheduled Maintenance: Delete One File
• HTTP 503: What Is Actually Broken When the Service Is Unavailable
• DNS Server Unavailable: A Fix-It Order That Starts With the Cheapest Cause
• Services on RunxBuild

FAQ

What does ‘it is temporarily unavailable due to maintenance’ actually mean?

The server returned an HTTP 503 status, usually with a Retry-After header, telling browsers and crawlers that the outage is planned and short. It almost always means a host, CMS, or application is mid-deploy or mid-update. It is not the same as a 404 (nothing there) or a 500 (something broke), and it should resolve on its own once the update finishes.

Why does my WordPress site get stuck on this message?

WordPress writes a .maintenance file to the site root when an update starts and deletes it when the update finishes. If the update times out or loses its connection, the file is left behind and the maintenance screen shows indefinitely. Deleting the file after confirming the update actually completed usually fixes it.

Does a maintenance page hurt SEO?

A short window with the right status code does not. The damage comes from returning HTTP 200 on the maintenance page, which lets crawlers index the placeholder as your real content, or leaving the window open for days without a Retry-After header telling crawlers when to come back.

How do I make my own maintenance page return the right status code?

On a server you control, configure it to check a flag file and return 503 with a Retry-After header for every request while the flag exists, as the nginx example in this post shows. On a static host, swap the deployed index page and keep the window as short as possible, since a true 503 is not always available there.

How long should a maintenance window last?

Minutes, ideally. Under ten minutes needs no communication at all. Past a couple of hours, treat it like an incident: state a reason and an estimate somewhere visible. Past a day, crawlers may stop trusting the Retry-After value and re-crawl on their own schedule, which is when a stale page risks getting indexed.