2 Geeks Web Design
How to create a custom error page for maintenance mode
A maintenance screen is often the first direct evidence of how a business handles disruption. It should reassure customers, protect search visibility, and keep useful actions available while an online booking, checkout, or client portal is paused. For owner-operated Australian businesses, where one staff member may handle marketing, support, and hosting, a generic browser error feels especially careless. A clear temporary notice in the company’s colours and voice is more reassuring than a raw server message.
Technically, the response should distinguish a temporary service interruption from a broken link. A planned outage belongs behind HTTP 503 Service Unavailable, ideally with a Retry-After header and a noindex directive. Returning 200 makes the site appear complete to crawlers, while 404 wrongly suggests the address has disappeared. An unexpected incident needs the same technical treatment but different wording and support details. This is the basis for a custom error page used in maintenance mode: design the response, not just the artwork.
A sound process starts with the customer’s next task. Can they call, email, read an update, or place an order through another channel? At 2 Geeks Web Design, the Princeton, Illinois-based studio applies its personalised design and hands-on development to these small but important details. A static page, tested server configuration, and concise copy deserve the same care as the main website, giving clients an orderly experience when something cannot stay online.
Plan the message before the design
Start by defining what the holding page must accomplish. Separate visitors into people trying to complete a transaction, existing clients looking for information, and search engines checking the domain. Each group may need a different first action, but all need the same factual core: what is unavailable, whether data is safe, what is expected, and where to get help.
Build the visual and verbal identity from assets the business already uses. A brand colour guide can prevent the temporary screen from looking like a different company. Keep the logo, typefaces, spacing, and tone consistent while checking that foreground and background colours remain readable. Choosing an accessible palette before layout work begins makes the remaining design decisions simpler.
Write Australian English plainly and avoid inflated apologies. “We’ll be back shortly” is weak when the restoration window is known; “Online bookings return at 4 pm AEST on Tuesday, 14 May” gives customers something actionable. Use the relevant state time, including AEDT during daylight saving, and spell out dates where confusion is possible. If the window cannot be promised, state that updates will appear at a specific time instead.
Build a page that feels like your business
Design mobile first because most Australian customers will meet the interruption on a phone, often over a mobile connection. Keep the page light, with one clear message, a short support block, and large tap targets. Avoid auto-playing video, animated backgrounds, and remote font or script dependencies; each extra asset can delay the very reassurance the page is meant to provide.
Make accessibility part of the artwork rather than a late audit. Use semantic headings, a logical focus order, visible keyboard focus, descriptive link text, and strong colour contrast. The page should still work with images disabled, CSS partially unavailable, or a screen reader reading it aloud. A concise status sentence can be announced clearly, while decorative elements should remain hidden from assistive technology.
Give the copy a human, locally natural rhythm without forcing slang. Words such as “arvo” may suit a relaxed Melbourne or Byron Bay brand, while “no worries” can soften a minor delay, but neither replaces useful facts. For visual inspiration, a distinctive independent project such as the Platov site can offer ideas for personality and presentation. Adapt the direction to the small business rather than copying another site’s layout.
Choose the right serving method
The page needs a reliable delivery route even when the main application is down. A static HTML document on separate hosting is the simplest failover; a CDN error page can serve the same file from the edge. A reverse proxy gives more control but adds configuration work, while an application flag integrates neatly with some hosting platforms. The best choice depends on who operates the server and which failure it must survive:
| Approach | Best suited to | Main advantage | Main trade-off |
|---|---|---|---|
| Separate static host | Sites needing resilience from the primary application | Keeps a lightweight notice reachable when the app or origin is unavailable | DNS and provider setup add another moving part |
| CDN custom error | Faster global delivery and established edge infrastructure | Low latency and strong reach across Australian cities | Requires provider configuration and careful cache control |
| Reverse proxy | Teams comfortable with server administration | Controls routes, headers, and outage handling | Adds operational responsibility and possible proxy errors |
| Application flag | Platforms with a reliable deployment workflow | Simple updates and one codebase for most content | May be unreachable if the application fails to boot |
Whichever route is chosen, return a genuine 503 status and set Retry-After to the number of seconds until the next check, or to an HTTP date. Redirecting visitors to the holding page with a 302 hides the temporary condition and can confuse monitoring. Add a robots noindex directive as a second layer, and avoid caching the outage response for so long that it survives the restoration.
For Nginx, a compact starting point is below. Replace the root path and interval for the site, then test the complete response rather than only viewing the HTML.
error_page 503 /maintenance.html;
location = /maintenance.html {
root /var/www/site;
internal;
}
add_header Retry-After "3600" always;
On Apache, use an ErrorDocument 503 rule with mod_headers to set the same retry interval. Confirm both the visible content and the response headers from an external network.
Test it like a real Australian visitor
Test the holding page at the moment a real outage occurs, not only in a design preview. Check current iOS and Android browsers, common desktop browsers, keyboard navigation, screen readers, slow mobile connections, and a direct visit to the maintenance URL. Refresh repeatedly and confirm that forms, checkout attempts, and account actions either fail clearly or remain safely available according to the business’s plan.
Regional checks matter in Australia. A Perth customer can be two hours behind Sydney and Melbourne during eastern daylight time, so a vague “later today” may already be too late. Test from at least one eastern and one western connection, and verify that phone numbers, opening hours, and email addresses work for regional customers. Byron Bay businesses should also consider international visitors who may need clearer timezone and date formatting.
Operational testing should confirm that the 503 status, Retry-After value, and cache settings behave correctly through the CDN, host, and search-console tools. Record who can restore service and how quickly. The same methodical, evidence-led approach used in the Project Astromech build journal is a useful model: document each test, capture the result, and retain a tested rollback route rather than relying on memory during a stressful incident.
Keep customers moving while the site is down
The holding page can do more than explain an outage. Keep the customer journey useful by offering a direct contact route, preserving access to a status update, and explaining what happens to an interrupted transaction. Australian customers will usually appreciate a specific phone number or email address more than a generic contact form, particularly when trading hours differ between states.
Four practices deserve attention before launch:
- State the unavailable service, affected region, and next update time using Australian date and timezone formats.
- Offer lightweight alternatives such as a telephone number, monitored email inbox, booking form, or order-enquiry link.
- Protect critical data by preventing writes and duplicate payments while the underlying application is unavailable.
- Assign an owner, review the notice regularly, and revise it whenever the restoration estimate changes.
Treat these points as a launch checklist and test each one under the same conditions used for the outage. If a customer can complete the essential alternative action without waiting for the main site, the temporary experience remains controlled and credible.
Measure, refine, and restore
Measure the interruption with the same care as the design. Track when the 503 begins, how long it lasts, which routes trigger it, support contacts, failed transactions, and recovery time. Compare those signals with normal traffic rather than judging the page by impressions alone. Logs should capture enough detail to diagnose the failure without exposing stack traces or personal information on the public screen.
Restoration should follow a fixed sequence: confirm the application is healthy, place the new release behind the normal checks, purge stale outage pages, switch traffic back, and monitor for renewed errors. Keep the holding page available in the repository or hosting account so the next incident does not begin with a blank file hunt.
A successful maintenance experience combines accurate status codes, fast delivery, accessible presentation, honest timing, and a usable fallback path. It protects trust while the business repairs the underlying issue and leaves search engines with a clear temporary signal. For a small-business website, that quiet reliability often matters more than a dramatic visual effect.