⌘⌥A. Reading incidents
requires alerts.read; acknowledging and resolving require alerts.acknowledge, and silencing requires
alerts.silence. Alert notifications received through a Feishu app or Slack app can also be
acknowledged and resolved on the card; see Alert cards.
Incident states
An open incident resolves by itself when the rule meets its recovery condition.
An acknowledged incident stays acknowledged until someone resolves it. Each rule, or each group of a
split rule, has at most one active incident at a time.
The incident list
The head of Incidents counts the affected services, the incidents that wait for acknowledgement, and the incidents recovered in the last 24 hours. A summary says how many incidents fire now, how long the oldest has been firing, and how many rules are evaluated. Recently recovered lists what ended lately. Switch between Firing and Waiting, the incidents that have no owner yet. Each row shows the severity, the incident and its service, the state, the duration, and the owner, with three actions:Incident details
Select an incident to open its details. The head shows the state, the time it fired, the rule, and how long it has fired, with Acknowledge, Silence, and Resolve.AI root cause
When Mole Agent is set up with a model provider, it analyzes new incidents in the background and stores an evidence-based result with the incident. Generate asks for one at once, and Regenerate replaces it. Rate a result with Helpful or Not helpful; the ratings feed Quality. Generating requires Mole Agent permissions. Once the Mole Agent token budget of the organization for the day is used up, automatic analysis pauses, and generation on demand follows the budget setting. See Usage and budget.Groups of incidents
Semantic groups collapse related incidents, for example all critical incidents of one service, into one group. Acknowledging or resolving a group withPOST /api/v1/alerts/incident_groups/{id}/ack or /resolve does the same to every member.