Review the Support-to-Incident escalation process
This incident exposed a gap between early customer-impact signals, engineering investigation, and incident declaration.
Task: Review and update any changes required the Support process to escalate repeated customer reports of the same production failure to incident management.
Example of Acceptance Criteria:
- Define incident-review triggers, including two independent customer reports or confirmed customer impact.
- Standardize links among Zendesk, engineering issues, and incident records.
- Assign a Support and Incident Management owner for each handoff, with an acknowledgment SLA.
- Record the decision to declare, monitor, or not declare an incident, including rationale.
- Validate the workflow through a tabletop exercise and the next applicable production issue.
Context: gitlab-org/gitlab#609534 (closed)
This ticket was created from INC-13111 using incident.io
Contributing cause this Corrective Action addresses
Customer-impact signals from Support reached the incident response team only after several days of accumulated Zendesk tickets — deletions had been silently failing since 5 August 2026, yet a Severity 2 was not declared until Support surfaced seven related tickets in the responder channel. The escalation happened reactively: a responder asked Comms to check for customer tickets, Support confirmed multiple reports, and only then was severity upgraded. No structured process existed to trigger incident declaration based on aggregated customer reports, standardize traceability between Zendesk, engineering issues, and incident records, or assign ownership and acknowledgment SLAs at each handoff point. The linked work item (gitlab-org/gitlab#609534 (closed)) and the tracking issue (#29567 (closed)) document this gap.
Proposed Action
Define and document an updated Support-to-Incident escalation process — captured in the linked work item gitlab-org/gitlab#609534 (closed) — that: (1) establishes explicit escalation triggers (e.g., two or more independent customer reports of the same production failure, or confirmed customer impact); (2) standardizes bidirectional links among Zendesk tickets, engineering issues, and incident.io records; (3) assigns a named Support owner and Incident Management owner for each handoff, each with a defined acknowledgment SLA (suggested — confirm with assignee); (4) requires a recorded decision — declare, monitor, or do not declare — with rationale; and (5) validates the workflow via a tabletop exercise and confirms it holds on the next applicable production issue.
Last updated by inc-automate on 2026-08-18 04:32 UTC · synthesis model: claude-sonnet-4-6 · request id: effd377c6dec06a0.