Skip to content
allanninal.dev/build
Collaborate

Part 4 of 7 · Uptime status poster series ~5 min read

How the status page stays up

This is the post that justifies building rather than buying. Every hosted status page gets independence right by construction; a homegrown one gets it right only if somebody thought about it, and it is easy to build one that shares four separate dependencies with the thing it monitors.

Key takeaways

  • Different region, different bucket, different distribution, different account if you can.
  • DNS is the dependency you cannot fully escape, and the mitigation is a second name.
  • Plain HTML, no JavaScript, no fonts, no analytics. It has to render on a bad connection.
  • The page is written on every state change and on a heartbeat, so staleness is visible.
  • If publishing fails, the last page stays up and says when it was written.

What independence means

DependencyThe mistakeThe fix
RegionSame region as the appA different region, chosen deliberately
AccountSame AWS accountA second account, if you have one
DistributionSame CloudFront as the siteIts own distribution and bucket
DNSSame hosted zone as the appA separate zone, ideally a separate registrar
Build pathDeployed by the same pipelineWritten by a Lambda, not a deploy
The page itselfRenders by calling an APIStatic HTML with the status baked in

The last row is the one that most often goes wrong in a homegrown status page. A page that loads and then fetches the current status from an API is only as available as that API, which is frequently the thing that is down. The status has to be in the HTML, written at the moment it changed.

The DNS problem

How a customer reaches the status page during an outageA vertical chain of five steps entered by a box labelled A customer types status.example.com. Step one resolves the name, which needs DNS to work; if your zone is the problem it exits to an alarm where nothing resolves. Step two reaches the distribution, which is separate from the application. Step three fetches static HTML with no API and no JavaScript. Step four renders on a bad connection. Step five is a working status page during an outage. A note says the first exit is the honest compromise, because a shared zone is a shared fate.AWS ACCOUNTA customer typesstatus.example.comResolve the nameneeds DNS to workYour zone is the problemnothing resolveszone downReach the distributionseparate from the appFetch static HTMLno API, no JavaScriptRenderon a bad connectionA working status pageduring an outageThe first exit is the honest compromise: a shared zone is a shared fate.
Fig 1. The path a customer takes to your status page during an outage, and the one dependency that cannot be fully removed without a second domain.
  • Machine learning
  • Networking
  • Management
  • Front-end & mobile

The honest compromise

If your status page is a subdomain of your main domain and the main zone has a problem, the status page is unreachable. That is a real dependency and the full fix is a second domain at a second registrar, which most small businesses will reasonably decide is more than they want to maintain.

The middle position is worth knowing: a separate hosted zone for the status subdomain, delegated from the main zone. It does not survive the parent zone being deleted or the registrar suspending the domain, and it does survive the far more common case of somebody breaking a record in the main zone. That is most of the benefit for a twenty-minute setup.

Why no JavaScript

Because the people reading a status page during an outage are disproportionately on phones, on poor connections, in a hurry. A page that is fourteen kilobytes of HTML and inline CSS renders instantly on anything; the same page with a framework, a font and an analytics tag does not, and the failure is invisible to whoever built it on a desk connection.

When publishing itself fails

How the status page behaves when publishing failsA horizontal row of five boxes. Status changes: the page is written. Heartbeat write: every five minutes. Publisher fails: the page stops updating. Page says when: showing as of fourteen oh two. A reader can tell: it is stale rather than wrong. A note says a page saying all operational with no timestamp is the worst possible failure.A STALE PAGE THAT ADMITS ITStatus changespage writtenHeartbeat writeevery 5 minutesPublisher failspage stops updatingPage says when'as of 14:02'A reader can tellstale, not wrongA page saying 'all operational' with no timestamp is the worst possible failure.
Fig 2. How the page fails safely. The timestamp is what turns a stale page from a lie into a readable signal.
  • Machine learning
  • Management
  • Outside AWS

Writing the page on a heartbeat as well as on state change is what makes the timestamp meaningful. A page that only rewrites when something changes will legitimately show a timestamp from three days ago, which is indistinguishable from a broken publisher.

With a five-minute heartbeat, a timestamp more than about ten minutes old means the publisher has stopped, and a reader who notices that has learned something true. It is a small piece of honesty that costs one scheduled invocation.

Next: the incident note, and closing it.

All posts