Setting up a status page: why status is learned from complaints
The service is degrading: response time is growing, some requests fail with errors. Monitoring sees this — the on-call engineer receives an alert, engineers open dashboards and begin investigating.
Meanwhile, customers write to support, “is everything broken?”, and the first confirmation of the incident comes from there, not from the status page. Adjacent teams learn about the outage even later — from chat or social media.
The cost of such a gap is measurable. The flow of support requests grows faster than the outage itself lasts: dozens of identical messages, manual replies, escalations.
Instead of fixing the root cause, engineers spend time explaining, and there is no public service status they can point to with a single link.
The reason is usually one: the status page lives separately from the monitoring system. Components are set up manually, updates are manual, and after an alert you need to remember to go into the admin panel and write text.
While this happens, users are already discussing the incident, and the entry appears after the fact — when everything has been fixed.
Setting up a status page begins with the opposite: components are tied to real checks, and status changes when a deviation occurs, without a manual step. Then comes incident notification for subscribers, outage history, and clear transparency of service operation. We break down how to build this.
What a public status page and its automation provide
A status page is not a marketing section but a separate environment: an independently hosted frontend, an API for updating components, and customer subscription to notifications by email and messengers.
While entries are made manually, the on-call engineer first deals with the incident, then agrees on wording, and only then does something appear publicly.
The silence window stretches for tens of minutes — exactly those minutes when customers already see errors and write to support.
Automation stitches the page to monitoring: a triggered alert moves the relevant component into a state of partial degradation, publishes an entry with a timestamp, and sends a notification to subscribers. A template inserts the draft text; the on-call engineer only has to confirm or reject it.
So that the page does not turn into a feed of noise, publication is triggered only by a signal that persists longer than a specified window, and incident closure is recorded as a separate entry.
Ready-made services like Statuspage cover publication and subscriptions, but require monitoring to be able to call them; solutions deployed in your own environment give full control over history and access.
Then the measurable effect begins.
The time from the first monitoring signal to publication is reduced from half an hour of manual approvals to 2-3 minutes, and the share of requests like “what happened to you” drops several times over: the customer sees the service state and expected recovery time before opening a chat with support. The on-call engineer stops manually multiplying the same reply and focuses on recovery.
A whole class of conflicts also goes away: “we didn’t know you had an outage.” The incident history with timestamps, updates, and affected components remains public — the customer can compare it with their logs at any time, and the team gets ready material for a post-recovery review. Service transparency becomes not a promise but an artifact visible from outside.
Options for hosting a status page and their limitations
A status page is valuable exactly at the moment when the main environment is down: if the storefront runs on the same servers as the product, during an outage it goes down with it.
Therefore the first selection criterion is isolation from the main environment, and the second is availability of the status page during degradation of the network, load balancers, and DNS.
Then the choice comes down to three schemes, and the difference between them is who is responsible for the availability of the storefront and how deeply it needs to be connected to monitoring and on-call systems.
| Option | When it fits | Limitations |
|---|---|---|
| External status platform | No in-house team to maintain the storefront, need rapid launch | Incident data is stored with the provider, weak customization of publication scenarios, dependence on its availability |
| Own status page frontend | Full isolation and custom publication scenarios required | A separate environment and domain are needed; the frontend itself becomes a service with updates and on-call duties |
| Hybrid scheme | Publication must be automatic, but there is no own infrastructure for the frontend | Two sources of truth; state synchronization and protection against incident data divergence are needed |
In practice, the scheme is chosen based on two questions: how quickly an incident must get onto the page, and whether we are ready to maintain a separate service for this page.
If automatic publication is needed but there is no own frontend, the hybrid gives a workable compromise: the external platform maintains availability, while internal systems send degradation and recovery events.
Setting up notifications and incident automation
Incident automation rests not on the status page itself but on whether it is honestly fed by signals from below. We start with an audit: which monitoring systems watch the services, which alert rules are configured, and who receives them at night.
We build the connection to the monitoring system so that status changes when an outage occurs, not from the on-call engineer’s memory.
- Audit of signal sources. We compile into one list the monitoring systems, build system events, external availability probes, and support requests. For each source we record the owner and decide whether it deserves publication on the page.
- Relationship scheme. The map “page component ← alert group ← signal source” shows which outage will take down half the services and which will go unnoticed.
- Trigger threshold. We treat a sustained deviation as an incident — by duration, share of affected requests, error class. Confirmation delay and duplicate suppression dampen noise so the page does not blink.
- Incident message templates. Drafts for degradation, full outage, and planned maintenance: what is happening, who is affected, what the user should do, when to expect the next update.
- Automatic publications. The rule “signal → status draft → on-call confirmation → publication,” timer-based updates, and automatic closure upon recovery.
- Test on a training incident. We run the full cycle on a test service and measure the time from trigger to publication — it immediately shows where the threshold is too sensitive and the template is unreadable.
- Handover of regulations. We provide the on-call engineer with instructions, an action checklist, and a matrix of access to publications.
After this, the status page stops being a manual chronicle and becomes an extension of monitoring — with predictable response time.
Regulations, schemes, and access: what remains with you
We hand over not access to our panel but documentation by which your team independently sets up, changes, and troubleshoots the status page.
The artifacts live in your repository next to the code and are edited through normal approval — context is not lost when on-call engineers or contractors change.
- Integration scheme: which systems send events, which trigger creates an incident, where the bottleneck is, and how publication behaves when monitoring fails.
- Role and access matrix: who declares an incident, who confirms, who publishes, and who closes it; separately, rights to edit text and to manually bypass automation.
- Incident publication regulation: criticality levels, time to first publication from trigger, update frequency, criteria for moving to “recovered” and “review completed.”
- Notification templates: drafts for the first publication, interim update, and review summary with variable substitution — the on-call engineer does not compose text under load.
- On-call instructions: a one-screen checklist — what to check, how to open an incident, whom to involve, how to roll back a publication.
- Escalation regulation: contact ladder with roles and response times, rules for escalation when confirmation is missed.
- Component and owner map: what is assigned to whom, where the failure points are, and which dependencies are external.
After a month of operation, this is exactly what reduces response time: the on-call engineer does not figure out who is right but opens the checklist and follows it.
Case: how incident publication time was reduced
Before implementing the status page, publication was manual: the on-call engineer learned about an outage from the support chat, wrote wording, agreed on it with the manager, and only then posted it.
From detection to the first entry on the page took 18 to 25 minutes, and during peak hours up to 40. All this time support received dozens of identical requests about the same thing, and customers received different answers from different channels.
We linked availability checks and business operations to page components: a monitoring signal opens an incident with a ready template, and the on-call engineer only has to confirm or reject it with one action.
Atlassian Statuspage took over sending updates to subscribers and incident history, while manual text entry remained only where separate wording for the customer is needed.
After this, the first publication fits into 2-4 minutes, about 90% of incidents go to the page without manual input, and the flow of identical support requests decreased by about three times.
Most importantly, a whole class of failures went away: “silent degradation,” when the service responds but some operations fail, and desynchronization, when the page is all green but customers already see errors.
We review each incident by chronology: signal, publication, first support request. Discrepancies turn into new checks or template edits — that is why recurring failures stop coming back.
How a status page differs from monitoring
Monitoring and a status page are fed by the same checks but answer different questions. Monitoring says “what broke inside”: it compares metrics and synthetic requests with thresholds, groups triggers, and escalates to the on-call engineer.
The status page answers outward — “what should the customer know about this and when.” The first system is addressed to the engineer, the second to the user and their support service.
The separation of audiences sets a different level of detail. The on-call engineer needs the metric, node, and graph; the customer needs the affected components, the nature of degradation, and the time of the next update.
If every trigger is broadcast outward, subscribers will receive emails about a latency spike that no one noticed. The opposite mistake is more expensive: silence while some users cannot log in.
The working model is a single source of truth for the incident. An incident is created once, and everything flows from it: an internal alert to the on-call channel, a component state change, a history entry, an email and notification to subscribers. Support stops retelling the outage manually, and wording does not diverge between channels.
Full automation of publication is rarely needed: usually update templates and a rule are configured by which the draft goes outward immediately or after on-call confirmation.
Tools like Statuspage cover the mechanics of subscriptions, history, and templates, but the boundary of “what counts as a customer incident” is described by the team — automation without this rule turns into a generator of false mailings.
Frequently asked questions about deploying a status page
Doubts around a status page are almost always engineering-related: will it itself survive an outage, will publication turn into a separate incident, and will internal infrastructure details leak outward.
Below are answers to the questions that most often arise before deployment begins. We design status as a separate environment, not as a section inside the main product.
What happens if the status page itself goes down?
It is hosted in a separate environment: its own domain, a platform independent of the product, and its own database. Updates are collected as static files, so the page responds even when the application is down.
If the main environment is unavailable, status remains the only live communication channel — that is its purpose.
Is it necessary to publish the whole picture outward?
No, the environments are separated. The public part shows only affected services and the degree of degradation — without node names, error codes, and internal tickets.
The internal part lives behind authentication: there the incident is tied to systems, on-call engineers, and chronology, and the public update text is formed from it.
How do you filter out false publications?
An incident is opened by a confirmed observation signal and with a delay: a short spike does not create a public message. The draft is assembled automatically, but goes outward either after on-call review or by rule if the duration exceeded the threshold. Thus a single restart does not turn into a public announcement.
What data must not be exposed outward?
Host names, internal service addresses, error texts, release plans, and personal data do not enter the external environment. Update wording is defined by templates in advance, and variable fields are substituted from the internal part. This protects both from unnecessary customer questions and from infrastructure reconnaissance.
Let’s discuss the task and come back with an estimate and plan
For the estimate to be substantive rather than “about this much,” we need only a description of your current environment: which services the customer sees, how they learn about their unavailability, and who currently answers questions.
Below is what to send so that we come back with a scheme of connections, a work sequence, and timelines, rather than general promises.
- List of services and their criticality: what the customer notices immediately and what can wait until morning.
- Where signals come from: monitoring systems, external availability checks, on-call shift alerts.
- How outages are reported now: chats, mailings, calls — and how much time this takes for the on-call engineer.
- Access and role requirements: who is allowed to change service status and who only reads.
- Customer channels: email, messenger, website widget, separate status page.
- History of recent incidents: how quickly users learned about them and from where.
- Constraints: change window, approval procedure, which services can be taken into a pilot launch.
Then we review your environment and propose how to connect the status page with monitoring: from automatic transition of a service into an outage state to manual confirmation by the on-call engineer.
Describe the task — we will come back with a work estimate, an implementation plan, and a clear answer on where to start.