Incidents

An incident starts with a summary, affected service and asset, then gets a priority and an assigned person. The status shows whether the work is open, acknowledged, under investigation, resolved or closed. Opened, acknowledged and resolved dates let the team review the sequence later. An incident should remain understandable to a colleague who was not present for the first alert.

The assigned responder checks the service and asset before assuming a cluster observation explains the issue. Workload readings can support an investigation, but the incident is where the team records service impact and the operational decision.

• Intake. Incident Responder creates the incident with a service, asset and clear summary.
• Ownership. The responder assigns a person and records acknowledgment as work begins.
• History. Attributed updates record what was observed, decided and communicated during investigation.

Use incident updates for dated narrative. Each update links back to the incident and names its author. That keeps a shift handoff from depending on a message thread detached from the operational record. A new update should describe a real event or finding, not merely repeat the current status.

Agree on who receives a new incident and how priority is selected. Decide when an incident is acknowledged, what information is required to mark it resolved, and who confirms closure. Map people to application users so an assigned person and an update author remain attributable.

If alerts arrive from an outside monitoring system, agree on the event identifier and which fields it may populate. Review the event receipt and the resulting incident separately. A received event is evidence of delivery; it is not automatically proof of an investigated or resolved incident.

A checkout service suffers intermittent failures while a workload has fewer ready replicas than desired. The responder creates an open incident for the service and affected asset, sets priority, and assigns the on-call person. After acknowledgment, they add an update naming the cluster observation and the investigation result. The next responder sees the same incident, owner and dated explanation.

If a change restores readiness, the Platform Operator records a later observation. The Incident Responder reviews that reading and the service outcome before resolving the incident. The Change Approver’s decision on the change remains separate from the incident’s resolution decision. The dates and updates should show which happened first. A resolved status without a usable update would leave the next shift guessing why the service was considered healthy.

• Active incident board — Group open, acknowledged and investigating service issues by status.
• My incidents — Find issues assigned to the current responder.
• Incident update history — Read dated, attributed investigation notes.

Follow incident investigation and problem investigation for recurring issues.