Status Report Reference

A status report is a chronological update or event associated with an ongoing incident in openstatus. These reports are crucial for communicating the progress of an incident, from initial detection to final resolution, providing transparency to stakeholders.

Purpose:

• Document the lifecycle and progress of an incident.
• Communicate current incident status and actions taken.
• Provide historical context for post-incident analysis.

Relationship to incidents

Each status report is directly linked to a specific incident. As an incident progresses through its resolution process, new status reports are added to provide updates, often accompanied by a change in the incident's overall status.

Configuration and properties

A status report consists of several key properties that define its content and context.

Status

Type: Enumerated string (required)

Represents the current stage or state of the associated incident at the time the report is issued. The available statuses are:

• investigating — the incident has been detected, and the team is actively looking into the root cause.
• identified — the root cause of the incident has been identified.
• monitoring — a fix has been deployed or a mitigation is in place, and the service is being monitored to confirm resolution.
• resolved — the incident has been fully resolved, and the service is operating normally.

Date

Type: Datetime (required) Format: ISO 8601 (e.g., 2026-01-05T12:30:00Z)

The timestamp indicating when the status report was created or when the reported status took effect. This provides a clear timeline for incident progression.

Message

Type: String (required)

A descriptive message detailing the update, actions taken, or any relevant information regarding the incident at the time of the report. This message should be clear and concise, providing context to the status change.

Example messages:

• "Initial detection of elevated error rates on the API. Investigating potential upstream issues."
• "Root cause identified as a misconfigured caching layer. Working on a rollback."
• "Fix deployed to production. Monitoring service health for full recovery."
• "All services restored to normal operation. Incident resolved."

Affected components

Type: Array of page component references (optional)

A status report can be attached to one or more page components on a single status page. The attached components define which services the report affects — they are highlighted on the public status page while the report is unresolved.

All attached components must belong to the same status page. Adding a component impact in a later update (see below) automatically adds that component to the report's affected set.

Component impacts

Beyond marking a component as affected, each update of a status report can declare how badly each component is affected. This per-component impact drives the component's live status, the report's overall indicator, and — for status pages using manual uptime — the uptime percentage.

Impact levels

Type: Enumerated string, set per component and per update

How impacts evolve over time

Impacts follow the timeline of the report's updates:

• Each update snapshots the impacts it sets. A component's current impact is the one from the latest update that names it.
• Components omitted from an update keep their prior impact — you only declare what changed.
• Resolving a report sets every still-affected component back to operational, so the status page clears deterministically.

Example timeline:

Update 1 (investigating): API → major outage
Update 2 (identified):    API → partial outage, Website → degraded performance
Update 3 (resolved):      API → operational,    Website → operational

After update 2, the API shows partial outage (latest update naming it) and the Website shows degraded performance.

Effect on the status page

• Component status: major_outage renders the component and its status bar red; degraded_performance and partial_outage render orange; operational renders green.
• Report indicator: the report's overall state is derived from the worst active component impact — it is not stored separately.
• Manual uptime: on status pages using manual uptime calculation, each interval between updates counts against uptime weighted by its impact:

Related resources

• Incident reference — detailed information on incident creation and lifecycle.
• Status page reference — how status reports are displayed on public status pages.
• Page components reference — the components a report and its impacts attach to.
• Uptime calculation — how impacts weight manual-mode uptime.