Skip to main content
An incident with wide impact that several people work on can be declared major: it gets three roles, can get a war room (a Feishu or Slack chat) and a meeting, has a task list, and its updates go to the war room and notify the people involved. The organization can also set a rule that makes matching new incidents major from the start. How the pages use it is in Major incidents and postmortems. Declaring, assigning roles, opening the war room, adding and finishing tasks, and posting updates are recorded on the incident’s timeline; declaring and saving the settings are also recorded in the audit log.

​
Declare

An incident already declared is returned as it is; a resolved incident cannot be declared. Declaring follows the organization’s settings:
  1. The settings’ checklist becomes tasks.
  2. A meeting is set up by meeting: feishu_vc has a Feishu App book a 6-hour Feishu meeting owned by the commander; tencent_meeting books a 6-hour Tencent Meeting; zoom starts an instant meeting; google_meet creates a meeting space; fixed_url uses the fixed meeting link.
  3. The connector of the settings (a Feishu App, Slack App, DingTalk, or WeCom one) makes a group chat named [severity] incident summary and adds the incident’s assignees, roles, and stakeholders (by the identities linked to that connector), with the commander owning DingTalk and WeCom groups; it posts an opening message with the incident and meeting links.
  4. Ticket connectors with on_major_incident create a ticket.
The war room, the meeting, and the tickets are best effort: what fails is only logged, and the declaration stands.
Declaring, reading, and assigning roles return { "response": { ... }, "tasks": [ ... ] }; response is null when the incident is not declared.

​
Roles and tasks

Assigning a role takes { "role": "scribe", "user_id": "<user-id>" }; a null user_id clears the role. The incident has to be declared first. Adding a task takes { "title": "…", "assignee_id": "<user-id>" }, with a title of 1 to 200 characters and at most 50 tasks per incident. A change sends only the fields to change: title, assignee_id (null clears it), and done; finishing a task records done_by and done_at. Adding and changing return the task, and deleting returns { "deleted": true }.

​
Post an update

At least one part has to say something, and each is at most 2000 characters; the incident has to be declared first. The update is recorded on the timeline, posted to the war room, and handed to the notify engine as the event incident.status_update, addressed to the incident’s assignees, roles, and the settings’ stakeholders and sent by the built-in policy Major incident update: notify the stakeholders. The event attribute status_update carries impact, current, next, and its author. Returns { "sent": true }.

​
Organization settings

The body is the whole settings object, and the saved settings are returned; before any save, a read returns the defaults. Secrets are stored encrypted with the root key: a read returns only secrets_set, the keys of the secrets that are set, plus the read-only war_room_types, the connector types that can make war rooms. Errors
Last modified on October 31, 2026