Guide 03 · Developer docs

The theme repo and the asset pipeline

Everything a developer changes on a Core dna site lives in its theme repository. This guide covers the repository and its build, printing records in templates, stylesheets and client-side code, and the parts of a site around the main content.

L1–L2
Unit 05 · Around the main content

Maintenance and failover pages

Around the main content Page 33 of 35 Updated

What a static failover page is, who serves it and when, what it must contain to be useful, and where its files live in a theme repo so it is ready on the day it is needed.

Who this is for. Developers and project leads preparing a site for go-live. After this page you can build a failover page that works while the site cannot answer, and keep it current in the repository.

What a failover page is

A failover page is a static HTML page served by whatever sits in front of the site, such as a load balancer, a CDN or the web server, when the application cannot answer a request. It is infrastructure rather than a platform feature: the platform has no maintenance mode, and no layout or admin screen configures one. When the page is served is decided by whoever runs the layer in front of the site, so agree the arrangement with them before launch.

What the page can depend on

The page is shown exactly when the application is unavailable, so it uses nothing the application provides: no template syntax, no CMS content, no images from the CMS asset library, no sign-in, no forms and no search. It can use files served as static files: the theme repo's dist/ folder, favicon.ico and the page's own folder.

Where the files live

Keep the page in the theme repo, in a failover/ folder at the root, so it is versioned and deployed with the site. A production site built this way keeps a handful of plain HTML files and an image folder there, none of them a template:

PathWhat it holds
failover/index.htmlThe page itself
failover/top-bar.html, side-panel.html, login-check.html, login-modal.htmlStatic copies of pieces of the live site's header and side panel
failover/assets/The page's own images: the logo and hero images

Its index.html does four things worth copying:

  • It links the live site's stylesheet from /dist/ with an absolute path, so it looks like the site without a second copy of the CSS.
  • It loads its images from /failover/assets/, not from the CMS.
  • It reloads itself every 20 seconds with <meta http-equiv="refresh" content="20">, so a visitor who lands on it is back on the live site as soon as it answers, without any JavaScript.
  • It reproduces the header and navigation as static markup, with the link text and addresses typed in.

A condensed version:

HTML failover/index.html 
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <meta http-equiv="refresh" content="20">
    <title>We will be back shortly</title>
    <link rel="stylesheet" href="/dist/app.css?v=2026-10-20">
</head>
<body>
    <header class="top-bar">
        <a href="/"><img src="/failover/assets/logo.png" alt="Example Company"></a>
        <nav>
            <a href="/">Home</a>
            <a href="/contact">Contact</a>
        </nav>
    </header>
    <main class="failover">
        <h1>We are very busy right now</h1>
        <p>The site is taking longer than usual to answer. This page tries again on its own every few seconds.</p>
        <p>To reach us now, call <a href="tel:+61300000000">1300 000 000</a>, or see <a href="https://status.example.com">our service status</a>.</p>
    </main>
</body>
</html>

What it must contain

  • The brand: the logo and the primary links a visitor expects, so the page reads as the site and not as an error.
  • A calm, honest message: what is happening, and that the page will try again on its own.
  • A way through that does not need the site: a phone number, or a status page on another host.
  • The automatic refresh, so the page clears itself when service returns.
  • Nothing that pretends to work: a sign-in button copied from the live header can only look like one, because nothing behind the page answers it. A failover page gives continuity and a way back, not features.
Plain HTML only

The platform never renders the failover folder, so Smarty or Twig in these files would reach the visitor as text. Write them as plain HTML and CSS.

Keeping it current

Nothing exercises a failover page in normal operation, so make checking it part of each release:

  • Commit the folder and its assets. They are source, not build output, and every deploy needs them. What must never be committed is the opposite list.
  • Follow the stylesheet. When a build renames the stylesheet the page links, update the link. A cache-busting query string in a static file is typed by hand and stays the same across deploys (Cache-busting asset URLs).
  • Follow the brand. When the site's navigation or branding changes materially, update the static header to match.
  • Look at it. Open /failover/index.html on each release candidate and check that the stylesheet and every image load.
Go deeper
GuideError templates GuideWhat is in a theme repository GuideCache-busting asset URLs GuideWhat must never be committed

Was this page helpful?

Your answer goes to the docs team.