A status page you update by hand, and when you need more
A status page has one job: during an outage, it tells customers what's broken, that you know, and when they'll hear more, so they stop filling your inbox. You can run one by hand from a CMS collection on Anticode. What Anticode doesn't do is monitor your service and flip a component to red by itself; for that you need a dedicated status tool.
What customers look for in the first ten seconds
- An overall state at the top: all systems working, degraded, or a named outage. Use words as well as colour; red and green alone fail colour-blind readers.
- Components in the customer's terms: "Web app", "Mobile app", "Payments", "Email delivery", "API". Not your internal service names.
- The current incident, if there is one, with the time of the latest update.
- Recent history: the last few incidents and how they were resolved.
- How to get updates: email, a social account, or wherever you post.
Writing incident updates
Incident updates are read by anxious people, sometimes by their bosses too. Follow a fixed rhythm and wording so readers can tell at a glance where things stand.
| Stage | What to write |
|---|---|
| Investigating | What customers are seeing, which components, when it started. "Some customers can't log in to the web app since 09:40 UTC. We're investigating." |
| Identified | That you know the cause, in plain terms, without blaming a supplier by name. |
| Monitoring | What you've changed and that you're watching whether it holds. |
| Resolved | When it ended, what was affected, and whether anyone needs to do anything. |
| Follow-up | A short write-up of the cause and what changes, a few days later. |
Always put the time and timezone on every update, and say when the next one will come ("next update by 10:30 UTC") even if there's nothing new. Silence reads as chaos.
Running it by hand from a collection
As a manual status page builder, Anticode works like this: keep incidents in a CMS collection, one entry per incident, with fields for the title, affected components, the current stage, start and end times, and the update text. Each incident gets its own page at /<collection>/<slug> and the collection's page lists them, which gives you an incident history for free. During an outage, whoever is on call edits the entry in the dashboard and adds the newest update at the top.
The overall state and the components list sit on the main page and are changed in the visual editor. Rehearse it once on a quiet day: time how long it takes to go from "we have a problem" to a published update, and make sure more than one person can do it. In a Team workspace, members can edit the site but can't take it down.
When you need a dedicated status tool
A hand-updated page fits a small product with occasional incidents and a team that's online when things break. It stops fitting when any of these is true:
- You promise uptime in contracts. You'll need measured uptime figures, which come from monitoring, not from an edited page.
- Outages happen when nobody's watching. An uptime status page should go red at 3am without waiting for someone to wake up.
- Customers want subscriptions to email or SMS alerts per component.
- You have many components or regions and incidents often affect only some of them.
In those cases use a dedicated status service that checks your endpoints and posts automatically, and link to it from your Anticode site's footer and help pages. Your marketing site and documentation can still live on Anticode; the status page lives where the monitoring is.
Building it
Describe it: "a status page for our booking app with components for web app, mobile app, payments and email, and an incidents collection". The Architect shows a plan before building. Publish it on a subdomain of your own domain such as status.yourapp.com on a paid plan, so customers find it where they expect. The documentation website and changelog page guides cover the neighbouring pages most products need.
Limits
- No monitoring, uptime checks or automatic status changes.
- No alert subscriptions. A newsletter form can collect emails, and you'd send updates yourself through Mailchimp or Kit.
- No uptime percentages or response-time graphs.
- No live refresh. Readers reload the page to see a new update.
Questions people ask
Should a status page admit to small incidents?
Yes. Customers who noticed a problem and find nothing posted trust the page less. Short, honest entries for minor issues build credibility for the big ones.
Can the status page be private to customers?
Not on Anticode. Published pages are public. Most status pages are public anyway.
Who should post updates?
Whoever is handling the incident, or a named communications person if the team is large enough. Agree it before the first outage.