Practical guide

Write Status Language That Matches the Evidence

A green badge makes a claim. When the newest observation is old, “Operational” says more than the source knows. When no observation exists, the same word invents the answer.

The safest status language is also the most useful. It tells readers what the supplied observation supports, then stops before certainty, scope, or cause enters the sentence without evidence.

Check freshness, scope, and cause before choosing a word

Start with freshness. A successful observation can support Operational only while it remains inside the stated freshness period. Once that period passes, the defensible label is Stale data because the old result no longer establishes present condition.

Then check scope. A fresh failure for one service can support Outage for that service. It cannot support “Major system outage” unless the evidence covers the wider system and the wording rules define that scope.

Finally, check cause. A status and timestamp do not show why something happened, how many people were affected, whether repair work has begun, or when another update will arrive. Those details need their own sources.

Use the narrowest wording the observation supports

Supplied condition	Supported label	Allowed wording	Reject this wording
Fresh successful observation, often called “up”	Operational	“Website: Operational. Last observation: [time].”	“Everything is working,” “100% uptime,” or “All systems operational” from one service record.
Fresh failure observation marked down	Outage	“Checkout: Outage. Last observation: [time].”	“Data was lost,” “Every customer is affected,” or “The cause is known” without those facts.
An observation older than the stated freshness period	Stale data	“API: Stale data. Last observation: [time].”	“Operational now,” “Still down,” or “Recovered.” The old result cannot establish the present.
No recorded observation	Unknown	“Billing: Unknown. No observation has been recorded.”	“Probably up,” “Outage,” or “The monitoring system failed.” Absence does not reveal a condition or cause.

The renderer evaluated for this guide uses healthy as its source term for a fresh successful observation, then displays Operational. It does not treat the informal word “up” as a separate input state.

The rendering rules preserve uncertainty

The proof follows six forced choices.

A fresh healthy source state displays Operational.
A fresh down source state displays Outage.
Any observed state becomes Stale data after its explicit freshness boundary passes.
A service with no recorded observation displays Unknown, even when its underlying record has advanced to another state.
At the exact freshness boundary, the observation remains fresh. One millisecond later, it is stale.
Each service card includes the last observation time, or states that no observation has been recorded.

In the verified examples, those inputs produced the listed labels in the HTML. That establishes predictable wording from supplied records. It does not establish any service condition beyond the supplied observation.

The same renderer also supports Degraded for a fresh late state and Recovering for a fresh recovered state. Use those labels only when the source carries those exact conditions.

Component status and incident narration are different jobs

Atlassian Statuspage gives hosted components five states: Operational, Under maintenance, Degraded performance, Partial outage, and Major outage. Its documentation ties those labels to the condition and scope of each component. (Atlassian component status definitions)

The service also separates component state from incident phases. Its incident flow uses Investigating, Identified, Monitoring, and Resolved, and can connect an incident with affected components and subscriber notifications. (Atlassian incident creation guide)

Those incident words carry claims about investigation, cause, repair, or resolution. A supplied state and timestamp do not establish any of them. Atlassian’s own templates distinguish a potential interruption from a full or partial outage, with separate placeholders for impacted services, user impact, and the next update. (Atlassian incident communication templates)

Statuspage also describes subscriptions, scheduled maintenance, API updates, and integrations as parts of its hosted communication service. (Atlassian Statuspage core features) A bounded snapshot-to-HTML file does not perform those functions. It applies defined wording to supplied records and stops after producing the file.

Know when wording review is enough

This approach fits when another source supplies the observations and one person needs to turn them into restrained, consistent text. It is especially useful when an old success must remain visibly old and a missing observation must remain visibly unknown.

It is a poor fit when the real job includes gathering status, maintaining a hosted destination, sending subscriber updates, coordinating response work, or writing an incident narrative from operational facts. Those functions require more evidence and a different system.

Takeaway

Choose a status word only after you can name the observation, its age, and its scope. Operational, Outage, Stale data, and Unknown are useful because each label stops at a different evidence boundary.

Mark the sentence you would refuse

Take one supplied snapshot and make four rows: fresh success, fresh failure, stale observation, and no observation. Write one sentence you would permit for each row and one you would refuse. Remove any sentence that adds scope, cause, impact, repair progress, or certainty absent from the source.