Commit 19e6475d authored by Vasilii Iakliushin's avatar Vasilii Iakliushin 🔴 Committed by Steve Abrams
Browse files

Clarify intermittent incident state transitions

parent df0d3c10
Loading
Loading
Loading
Loading
+8 −0
Original line number Diff line number Diff line
@@ -592,6 +592,12 @@ The entire incident lifecycle is managed through incident.io. All `S1` and `S2`

Incidents are [reported](/handbook/engineering/infrastructure-platforms/incident-management/#reporting-an-incident) and resolved when the degradation has ended and will not likely re-occur.

### Intermittent and self-resolving incidents

For intermittent or self-resolving incidents, keep the incident in `Active -> Investigating` while responders are actively investigating, or use `Active -> Fixing` while they are actively mitigating or recovering the service. When the service is healthy and responders are watching for recurrence, use `Active -> Monitoring`, including when no corrective action was taken or the cause is external and outside our control. If impact recurs, return the incident to Investigating or Fixing based on the response activity.

When the risk of recurrence is unclear, the Incident Lead should communicate how long the incident will remain in Monitoring before it is resolved. The observation period should reflect the incident's recurrence pattern and the responders' confidence in the recovery. Keep any customer-facing status.io incident active until recurrence is unlikely in the near term.

### Incident Lead

The Incident Lead is responsible for ensuring that the incident progresses and is kept updated. This role is deliberately assigned after the start of an incident.
@@ -649,7 +655,9 @@ Follow-up items are created by default in the [incident-follow-ups project](http
    A(Incident is declared) --> |initial severity assigned| B(Active->Investigating)
    A -.-> |If duplicate| Z(Merged)
    B --> |"Fix identified"| C(Active->Fixing)
    B --> |"Impact stopped; watch for recurrence"| D(Active->Monitoring)
    C --> |"Fix deployed"| D(Active->Monitoring)
    D --> |"Impact recurs"| B
    D --> |"Incident resolved"| E(Resolved)
    E --> |"S1 or S2"| F(Post-Incident Review)
    E --> |"S3 or S4"| G(Incident Closed)
+1 −0
Original line number Diff line number Diff line
@@ -14,6 +14,7 @@ title: Incident Roles - Incident Lead
6. Ensuring that the root cause is stated clearly and plainly in the incident description by updating the `causes` section in the `/incident summary`, or can be alternatively shared as an internal status update using emoji reactions. Reacting with the `:pushpin:` will post a public comment on the GitLab incident issue, reacting with a `:star:` will add an internal comment to the GitLab incident issue.
7. Ensure all follow-up items are properly documented and assign initial owners when possible.
8. Be available for customer interactions when requested by the Communications Lead. See [Communications Lead - Customer Call Management](communications-lead.html#customer-call-management).
9. For [intermittent or self-resolving incidents](/handbook/engineering/infrastructure-platforms/incident-management/#intermittent-and-self-resolving-incidents), keep the incident workflow state aligned with the response activity and communicate how long the incident will remain in Monitoring before resolution.

### After the incident