Website maintenance message: templates and examples

What every maintenance message needs

Readers want five facts. If one is missing, they write to your support team to ask for it.

• What: which parts are affected. Say "the website and checkout" or "sign-in", not "some services".
• When: the start and the end, with the date and the time zone, for example "14 November, 02:00 to 03:00 UTC". Add the local time for your main audience. Do not write "tonight" or "tomorrow": your readers live in different time zones.
• How long: the expected length. Add a margin, because work usually takes longer than the plan.
• What it means for the reader: what still works, whether they need to do anything, and whether their data is safe (only say this if it is true).
• Where to get updates: a status page or a social account. Host it away from the site you are taking offline, or it will be offline too.

Use short sentences and common words. Write "we are upgrading our servers", not "we are performing an infrastructure migration". Planned work needs no long apology and no blame. A common schedule is a first notice a week ahead, a reminder 24 hours ahead, a banner one hour ahead, a message when the work starts and a message when it ends.

Copy-ready templates

Replace each item in square brackets. Delete any line that is not true for your work.

Advance notice (email or announcement)

Subject: Scheduled maintenance on [DATE], [START] to [END] [TIME ZONE]

Hello,

We will update [SERVICE NAME] on [DAY AND DATE] from [START] to [END]
[TIME ZONE] ([START] to [END] [LOCAL TIME ZONE]).

What will happen: [the website, the app and checkout] will be
unavailable for up to [DURATION]. [Your data and orders are not affected.]

What you need to do: nothing. If you are placing an order, please
finish it before [START].

Updates: we will post progress at [STATUS PAGE URL]. We will email you
if the plan changes.

Questions: reply to this email or write to [SUPPORT EMAIL].

[TEAM NAME]

Banner on the site

Scheduled maintenance on [DATE], [START] to [END] [TIME ZONE]. The site will be unavailable during this time. Details: [LINK]

Maintenance starts in 15 minutes. Please save your work.

Maintenance page

The page is the one visitors see during the work, so keep it small and static. It needs no database, no scripts and no outside files. Google recommends static HTML with inline CSS for this page.

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>We are updating [SITE NAME]</title>
  <style>body{font-family:system-ui,sans-serif;max-width:36rem;margin:15vh auto;padding:0 1rem;line-height:1.5}</style>
</head>
<body>
  <h1>We are updating [SITE NAME]</h1>
  <p>The site is unavailable during scheduled maintenance.</p>
  <p>We expect to be back by <strong>[END TIME] [TIME ZONE]</strong>.</p>
  <p>Follow progress at <a href="[STATUS PAGE URL]">[STATUS PAGE URL]</a>.
     For urgent questions write to <a href="mailto:[SUPPORT EMAIL]">[SUPPORT EMAIL]</a>.</p>
</body>
</html>

Status page entries

Create the scheduled maintenance entry in advance, then add an update when the work starts and when it ends. Each update carries its own time.

Title: Scheduled maintenance: [COMPONENTS]
Scheduled: [START] to [END] [TIME ZONE]
Impact: [COMPONENT] will be unavailable for up to [DURATION].

[TIME] [TIME ZONE] - In progress: maintenance has started.
[COMPONENT] is unavailable.

[TIME] [TIME ZONE] - Delay: the work is taking longer than planned.
We now expect to finish by [NEW TIME]. Next update at [TIME].

[TIME] [TIME ZONE] - Completed: maintenance is finished and
[COMPONENT] is working again.

Social post and in-app notice

Scheduled maintenance: [SERVICE] will be offline on [DATE], [START] to [END] [TIME ZONE]. Updates: [STATUS PAGE URL]

[APP NAME] is being updated on [DATE] from [START] to [END] [TIME ZONE]. You will not be able to sign in during this time.

Serve the maintenance page with HTTP 503

Visitors see the same page whatever status code you send, but crawlers and monitoring tools do not. Use 503 Service Unavailable with a Retry-After header. A 503 tells search engines the outage is temporary. Google advises returning 503 for planned downtime, not 404 and not an error page with status 200, and notes that Retry-After gives crawlers an estimated time to come back. The 503 guide covers the header in detail.

• Do not send 200 for the maintenance page, and do not use 404 for it.
• Do not redirect every URL to a separate /maintenance address. Crawlers then see one page at every URL.
• Keep /robots.txt working. Google says that returning 503 for robots.txt blocks all crawling.
• Let your own team through, so you can test the new version before you reopen.
• Add Cache-Control: no-store, so a CDN does not keep the maintenance page after you reopen.

This nginx server block turns maintenance mode on when the file /var/www/maintenance.on exists and off when you delete it (TLS settings are left out):

server {
    listen 80;
    server_name example.com;
    root /var/www/example;

    set $maint 0;
    if (-f /var/www/maintenance.on) { set $maint 1; }
    if ($uri = /robots.txt) { set $maint 0; }
    if ($remote_addr = 203.0.113.10) { set $maint 0; }
    if ($maint) { return 503; }

    error_page 503 @maintenance;
    location @maintenance {
        root /var/www/maintenance;
        rewrite ^ /index.html break;
        add_header Retry-After 3600 always;
        add_header Cache-Control "no-store" always;
    }
}

In PHP, or in any application that can set headers, do the same at the top of the entry script:

<?php
http_response_code(503);
header('Retry-After: 3600');
header('Cache-Control: no-store');
readfile(__DIR__ . '/maintenance.html');
exit;

Always test the result, because a CMS or maintenance plugin may send 200 by default:

curl -sI https://example.com/ | head -4
HTTP/2 503
retry-after: 3600
cache-control: no-store

The value of Retry-After is a number of seconds or an HTTP date. It is a best estimate, so update it if the work takes longer. Keep the outage short: Google says a whole site should be disabled for a few days at most, because a longer outage has significant effects in search results. The website maintenance checklist shows where planned work fits in a regular routine.

Tell your monitoring and your status page

While the page returns 503, a monitor that expects 200 will see a failure and send alerts that nobody needs. HostTracker maintenance windows pause alerts for planned work and appear on the status page. A HostTracker status page shows each monitor as operational, degraded, partial outage or under maintenance, shows scheduled maintenance, and publishes incidents with timestamped updates. If the work goes wrong and the site does not come back on time, open an incident instead of extending the maintenance entry, so customers can tell planned work from a failure. The status page guide explains how to write those updates.

After you reopen, confirm the site from outside your own network. The website down checker tests the address live from independent checkpoints and shows what each one saw, so you can see that every location gets a normal response and not a leftover 503 from a cache. HostTracker checks from 300+ checkpoints in 158 cities, and its alerts go out by email, SMS, voice call, Slack, Telegram and more.

Frequently asked questions

Should a maintenance page return 200 or 503?

503 with a Retry-After header. A 200 tells search engines and monitors that the maintenance text is your real content.

What value should Retry-After have?

Use the number of seconds until you expect to be back, for example 3600 for one hour, or an HTTP date. Both forms are valid in RFC 9110. The value is a guess, so change it if the schedule changes.

How far ahead should I announce maintenance?

Early enough for users to plan around it. For work that stops customers from doing their jobs, a week is common, with a reminder the day before. For a few minutes at a quiet hour, a status page entry and a banner may be enough.

What if the work takes longer than planned?

Post an update before the announced end time passes. Give the new estimate and the time of your next update, and change the Retry-After value to match.

Can I redirect visitors to a maintenance URL instead?

You can, but a 503 is better. A redirect ends at a page that returns 200, so search engines and monitors treat the maintenance page as normal content at every address.

Sources and further reading

• Google Search Central: Pause or disable a website: the 503 best practices, static HTML, Retry-After and the robots.txt warning.
• RFC 9110, HTTP Semantics: the definition of 503 Service Unavailable and Retry-After.
• MDN: Retry-After: header formats and examples.
• nginx: ngx_http_headers_module: why add_header needs always on error responses.