Every app eventually needs a maintenance page — a scheduled migration, a hosting move, a database upgrade that requires downtime. Most teams don’t think about it until the night before, and end up either serving a raw server error or throwing together something generic in the last ten minutes before taking the site down.
This is about deciding what a maintenance page should actually say, and specifically why it shouldn’t be hosted on the same infrastructure you’re about to take offline.
Why “we’ll be back soon” isn’t enough
A maintenance page’s default content tends to say almost nothing useful — a generic message with no timeframe, no explanation, and no way to find out more. For a visitor, that’s indistinguishable from the site just being broken. The whole value of showing a maintenance page instead of a raw error is that it communicates “this is intentional and temporary” — a message that fails to do that isn’t really doing its job.
What it actually needs to say
- That it’s planned, not broken. Stated explicitly — “we’re performing scheduled maintenance,” not just silence or an error code.
- A realistic timeframe. “Back by 3pm UTC” is far more reassuring than an open-ended “back soon,” even if the estimate has some slack built in.
- Where to check for updates, if the maintenance runs long — a status page, a social account, wherever you’d actually post an update.
- Contact info, for anything urgent that genuinely can’t wait.
The obvious mistake: hosting it on the same infrastructure
This is the detail that gets missed most often. If your maintenance page is served by the same application, server, or database you’re about to take down for the maintenance itself, it goes down right along with everything else — visitors get a raw connection error during the exact window you most wanted them to see a clear, calm message instead.
A maintenance page needs to be genuinely independent — hosted separately, reachable regardless of what state your main infrastructure is in. Carrd is a reasonable fit here specifically because it’s about as decoupled as a page can be — no dependency on your app, your database, or your server, which is exactly the property you need during a maintenance window.
Setting it up before you need it
Build it once, reuse it every time
Maintenance windows happen more than once over a project’s life. Building a page you can quickly edit and redeploy — swap the timeframe, update the reason — beats building a new one from scratch under time pressure each time.
Point your DNS or load balancer at it deliberately
Decide in advance how traffic actually gets routed to the maintenance page during the window — a DNS change, a load balancer rule, or a redirect at your CDN level. Figuring this out for the first time during an actual maintenance window adds unnecessary stress to something that should be routine.
Test the whole flow once, calmly
Before your first real maintenance window, do a dry run — flip traffic to the maintenance page and back, outside of an actual deploy. It’s much easier to catch a routing mistake during a calm test than during a live migration with a ticking clock.
Deciding who needs to know in advance
The maintenance page handles people who show up during the window, but it’s worth separately notifying anyone who’d be meaningfully inconvenienced by not knowing ahead of time — an email to active users a day or two before a planned window, or a pinned post if you have a community space. The page catches the walk-up traffic; the advance notice is what prevents the maintenance from feeling like a surprise to the people who care most.
What to avoid
Avoid vague, over-apologetic copy — “We’re SO sorry for the inconvenience!!” reads as less professional than a calm, factual “Scheduled maintenance, back by [time].” Avoid leaving the page up longer than the actual maintenance window; a maintenance page still showing hours after you’re back online looks like a new, different problem.
Quick checklist
- State plainly that this is planned maintenance, not an outage.
- Give a realistic timeframe, not an open-ended “soon.”
- Point to a status page or social account for updates if the window runs long.
- Host it completely independently of the infrastructure you’re taking down.
- Test the routing flow once, calmly, before your first real maintenance window.
A maintenance page is one of those things nobody thinks about until the night before a deploy. Build it now, while there’s no pressure, and it’s a non-event the next time you actually need it.
Tested firsthand
