Incidents and updates

An incident names the service, affected asset, assigned person and priority. The Incident Responder uses those links to take responsibility for a disruption that needs investigation. Opening time, acknowledgment time and resolution time remain distinct. The service owner can see whether the issue has been accepted for work, is under investigation, or has been resolved.

The incident register carries the current status. Updates carry the running account of what happened, with an author and occurrence time. An update can explain a test, an observation or a handoff without replacing the incident’s summary. Keep those notes tied to the same incident so another responder can continue the investigation with the current context.

• Ownership. The assignee, service and asset make responsibility and impact visible.
• Response timing. Opening, acknowledgment and resolution dates answer different operational questions.
• Investigation history. Authored updates keep the narrative beside the incident.

Start in the incident queue and verify the service and asset before changing the status. At intake, the response workflow acknowledges a new incident or authorized inbound event and stamps the actual acknowledgment time. The assigned responder checks that the work reached the right person. Move into investigation as evidence is reviewed. Record observations as updates with the person who wrote them, then enter the resolution time once the service issue is addressed.

Agree what makes an alert serious enough to open an incident and who assigns the responder. Define the priority labels for the team and when a service owner must be involved. A service may contain several assets, so choose the actual affected asset instead of defaulting to the first one. Decide what belongs in an incident update so responders can distinguish observations from completed actions.

Check the user to person link before testing the personal queue. The assignee is a person record associated with a user; the team needs that relationship for the right responder to find the work. Confirm who may close an incident after resolution and what information the service owner expects to see first.

A log alert on a checkout stream draws attention to repeated failures. The Incident Responder opens a high-priority incident for the checkout service and its application asset, assigns a named person and records the opening time. The responder checks the acknowledgment and actual time recorded at intake. During investigation, they add a dated update describing the observed failure and another when the service recovers. Once verified, they record the resolution time and move the incident to resolved, then closed. The service owner can review the sequence without treating the alert’s closure as the incident’s closure.

• Incident queue — Review open, acknowledged and investigating incidents by priority and owner.
• My incidents — Let the assigned responder focus on their own dated work.
• Incident update history — Read the authored sequence attached to incidents.

Review alert to incident response and change review when repair requires a controlled change.