← Help & Docs

Major Incident Workflow

Bridge, subscribers, status broadcasts, auto post-incident review. ITIL Major Incident on top of TaskerTask. Last updated 2026-05-17

A Major Incident is an Incident-class TaskerTask (created with the ITIL Incident profile, §12by) that gets promoted with extra coordination fields: bridge URL, incident commander, subscribers, affected CIs, chronological status updates, and an auto-created post-incident review on resolve.

Lifecycle

  1. Incident exists as a normal Tasker task. Created via catalog, intake portal, MCP, or web UI.
  2. Promote to Major Incident: set bridge URL, incident commander, subscribers, affected CIs. Priority is forced to Critical. CMDB lookup rolls up max criticality of affected CIs. Initial status update posted + broadcast.
  3. Status updates posted during incident. Each one is logged chronologically and broadcast to subscribers via Graph or SMTP. Optional task status transition with each update (e.g. Investigating → Contained → Recovering).
  4. Subscribe / unsubscribe stakeholders dynamically as scope expands or contracts.
  5. Resolve: final RESOLVED broadcast, auto-created Post-Incident Review (PIR) task assigned to commander with 14-day due date and pre-filled checklist.

Declaring a major incident

POST /api/tasker/tasks/:id/declare-major (Admin). Required: existing TaskerTask id. Optional: bridgeUrl (Teams/Zoom/phone), incidentCommander (defaults to caller's email), subscribers[] (max 50, validated email format), affectedCiIds[] (up to 100, CMDB lookup rolls up names + max criticality), initialNote (first status update text).

Side effects: forces priority to Critical, sets isMajorIncident=true, denormalizes affected CI names and max criticality onto the task, posts the initial update, broadcasts to subscribers.

Status updates during the incident

POST /api/tasker/tasks/:id/major/status-update (Auditor+). Body: text (≤5000 chars), optional status (new task status, e.g. "Contained"), optional notify (default true).

Each update gets a unique id, timestamp, author, and is appended to the statusUpdates[] log. Broadcast email goes out to all subscribers unless notify=false (use false for internal-only notes).

Managing subscribers

POST /api/tasker/tasks/:id/major/subscribe (Auditor+). Body: emails[], action (add / remove). Email format validated. Subscribers receive every status update via email until removed.

Pattern: add affected user groups when scope expands. Remove people who no longer need updates (e.g. business stakeholder who left for the day).

Resolving + the post-incident review

POST /api/tasker/tasks/:id/major/resolve (Admin). Body: resolutionSummary (≤5000 chars), optional rootCauseCode (short label like "config-drift" / "vendor-outage" / "expired-cert"), optional skipPostIncidentReview (only for trivial false alarms).

What happens:

  1. Final RESOLVED status update posted with the summary, broadcast to subscribers.
  2. Task status set to Resolved; resolvedMajorAt, resolvedAt timestamps stamped.
  3. If !skipPostIncidentReview: a new TaskerTask is auto-created - title "Post-Incident Review: {original}", assigned to the incident commander (or caller if no commander), 14-day due date, category "post-incident-review", priority High.
  4. PIR task description includes timeline anchors (declared at, resolved at, duration), affected CIs, root cause code, and a pre-filled 8-item checklist (timeline reconstruction, RCA, detection time, response time, communication effectiveness, action items, lessons learned, stakeholder briefing).
  5. The PIR task id is stored on the original incident as postIncidentReviewTaskId for navigation.

Active incidents dashboard

GET /api/major-incidents/active (Viewer+) returns all currently-active MIs (isMajorIncident=true AND resolvedMajorAt is null) with elapsed time, subscriber/update counts, last status update snippet, max affected criticality. Use to populate war-room dashboards or check end-of-day whether any MIs are still open.

Email broadcast

Subscribers receive HTML emails for declared / update / resolved events. Color-coded headers (red declared / blue update / green resolved). Includes bridge link, commander, current status, posted timestamp, link to the task.

Delivery: Graph email config preferred → SMTP fallback. Per-recipient failure non-fatal - log + continue. Silent skip if neither configured (no error to caller, log only). Configure in Settings → System → Email Delivery.

On-call rotations

On-call rotations define who answers the page when a major incident is declared. A rotation is an ordered list of members plus a shift length and a start-date anchor; "who is on-call right now" is computed deterministically from the anchor, the rotation length, the member count, and the current time - there are no per-shift rows to maintain, so the schedule is self-correcting and never drifts. Requires an Ops product license and the on-call module.

What a rotation gives you:

Endpoints:

How paging ties into major-incident response: before (or right after) declaring a major incident, call GET /api/oncall/current to identify the responder on shift, then use their email as the incidentCommander and/or add them and the rotation's escalationEmail to subscribers[] so they receive every status broadcast. As the incident runs across a hand-off boundary, re-check nextHandoffAt and subscribe the incoming responder so coverage carries over without a gap.

MCP tools (5, HTTP + stdio parity)

CMDB integration

When declaring, pass affectedCiIds[] from your CMDB. The handler looks up each CI's name (denormalized to affectedCiNames[] on the task) and computes the max criticality across all affected CIs (stored as maxAffectedCriticality). Use get_ci_impact from the CMDB tool set BEFORE declaring to estimate blast radius and decide who to subscribe.

Pitfalls