Outages and impact

The incident tells responders what they are investigating. An outage record identifies the site, outage reference, start and restoration times, estimated impact minutes and the incident it belongs to. A service impact record names the monitored service, describes whether it is delayed or unavailable and links a service owner. These records let the team answer different questions: what was observed, how long the interruption lasted and which service was affected.

Consider an application that becomes unreachable at one site. The Monitoring Operator opens an incident after unsuccessful checks. The Incident Responder creates an outage record with the observed start time and site code. The Service Owner records the impact as unavailable and attaches the relevant degradation procedure when the team has one. During investigation, a later check succeeds. The responder verifies the service with the owner, records the restoration time and then resolves the incident. The outage duration should follow the recorded timestamps rather than a guess made during the first report.

• Outage chronology. Capture start and restoration times against the incident, preserving the original outage reference.
• Service effect. Use the impact value to distinguish a delay from an unavailable service.
• Recovery evidence. Review later availability checks and the responder’s updates before recording restoration.

Agree how site codes are assigned and which team supplies the outage reference. Decide when one interruption should be split into separate records across sites. Identify who may record an estimated impact and who confirms restoration. Make a clear distinction between a maintenance window and an unplanned outage. A maintenance window has opening and closing times with a timezone; it provides context for interpreting checks, while the outage remains a record of an observed interruption.

Use a test service with two sites. Record a failed check at one location and a successful check at the other, then open an incident linked to the affected service. Create an outage for the affected site. Ask the Service Owner to classify the impact and explain what customers experienced in plain language. When a later check succeeds, have the responder enter restoration time and a final update. The owner should be able to compare the outage chronology, service impact and incident resolution without treating them as the same field.

Repeat the test with a delayed service. The impact value should remain distinct from unavailable. If an outage has no restoration time yet, keep it in the unresolved queue so the team can follow up. Do not close the incident from an estimate alone; the team should review the actual recovery evidence.

• Unresolved Service Outages — Locate interruptions still awaiting a restoration time.
• Open Incidents — Read the investigation tied to each interruption.
• Failed Availability Checks — Review the observations that prompted the case.

Follow outage assessment to record impact and service recovery to confirm restoration.