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

Status reports are independent of incidents. An incident is the automatic, internal record opened by the checker when a monitor fails; a status report is the manual, public narrative you publish on a status page. There is no database link between the two — you decide what to communicate and when.

A status report belongs to a status page and optionally to a set of page components. As a situation evolves you append updates to the same report, each carrying its own status and message.

Configuration and properties

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

Title

Type: String (required) Length: 1–256 characters

The headline of the report, shown on the public status page, in the events feed, and in subscriber notifications.

Example: "Database connectivity issues"

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.

Updates

A status report is a timeline of dated entries. The first one is written at creation; later ones track progress until the resolution. Each update has:

• Status — the status the report moves to with this entry.
• Message — String (required). The public note.
• Date — Datetime (optional). When the entry applies. Defaults to the time it is posted.
• Component impacts — per-component impact declared by this entry (see below).
• Notify — Boolean (write-only). Sends the entry to status page subscribers. Optional over RPC and from the dashboard; the MCP tools require it so the agent states the choice explicitly. Only new entries notify; editing one never does.

The report's status is derived from its latest update by date, so editing or removing an update can change it. A report always keeps at least one update: deleting the last one is rejected; delete the report instead. Reads return the entries newest-first under updates (RPC), and the public status page renders them in order.

Entries are edited and removed from the dashboard timeline, through the UpdateStatusReportUpdate and DeleteStatusReportUpdate RPC methods, and through the update_status_report_update and delete_status_report_update MCP tools. All three accept resolved: setting the latest entry to resolved resolves the report without notifying subscribers, whereas resolve_status_report appends a new resolution update and notifies.

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 the uptime percentage. Reports only uses these impacts as its uptime source, while Monitor checks with Time per status also includes report intervals alongside monitor downtime.

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.
• Reports only uptime: on status pages using the Reports only status source, 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.