> ## Documentation Index
> Fetch the complete documentation index at: https://docs.molesignal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Work an incident from page to postmortem

> Acknowledge, size the impact, tell customers, find the cause across signals, recover, and learn, with the incident record as the single thread.

An incident is stressful because several things must happen at once: someone must own it, customers
must hear about it, and the cause must be found. Keep one thread: the incident in **Alerts**. Everything
else, from the status page to the postmortem, links back to it.

## Take ownership

Open the incident from the page, or **Alerts → Incidents** and the **Waiting** tab. Select
**Acknowledge** within the ack timeout. Acknowledging stops the escalation and shows the owner to
everyone who opens the incident, so nobody else starts the same work in parallel.

When several incidents fire for one cause, acknowledge the one that describes the cause, and
[silence](https://docs.molesignal.com/en-US/alerting/silences.md#silence-one-incident) the others while the work goes on. Incidents
collapsed by a [semantic group](https://docs.molesignal.com/en-US/alerting/silences.md#semantic-groups) can be acknowledged together
through the API.

## Size the impact

Read the [incident details](https://docs.molesignal.com/en-US/alerting/incidents.md#incident-details) before changing anything:

| Section | Question it answers |
| - | - |
| **Triggering query** | What crossed the threshold, by how much, and since when? |
| **Blast radius** | Which services and pages does the affected service reach? |
| **Sample sessions** | For a RUM incident, what did real users see? Each session has a replay. |
| **Cross-signal handles** | Which services, hosts, and traces are involved? |

Check the [SLOs](https://docs.molesignal.com/en-US/apm#service-level-objectives) of the affected services: a high burn rate means
customers feel it now.

## Tell customers early

When customers are affected, publish a [status page incident](https://docs.molesignal.com/en-US/status-pages#incident-lifecycle)
before the cause is known:

1. Create the incident as a draft, select the affected components and their impact.
2. Publish a first update in the **Investigating** state: what customers see, and when the next update
   comes.
3. Add an update at each change: **Identified**, **Monitoring**, **Resolved**. Published updates are
   never edited, only followed by new ones.

[Publication automation](https://docs.molesignal.com/en-US/status-pages#publication-automation) can draft the status page incident
from the alert, waiting for approval, so the first update is ready in seconds.

## Find the cause

Work from the symptom toward the cause, keeping the time window of the incident:

* **Open triggering query** replays the query that fired, and **Related logs** and **Related metrics**
  open the context around it. See [Cross-signal correlation](https://docs.molesignal.com/en-US/correlation.md) for the jumps between
  logs, traces, metrics, and sessions.
* Look for recent changes: the [deployment timeline](https://docs.molesignal.com/en-US/apm/deployments.md#the-deployment-timeline) of the
  service, and the changes listed [near an APM finding](https://docs.molesignal.com/en-US/apm/insights.md#changes-near-a-finding).
* Read the [AI root cause](https://docs.molesignal.com/en-US/alerting/incidents.md#ai-root-cause), or select **Generate**. Treat it as a
  lead to verify, and rate it **Helpful** or **Not helpful**.
* Ask [Mole Agent](https://docs.molesignal.com/en-US/agent) with **Investigate** on the service page, which attaches the service
  health, its neighbors, and the findings to the chat.

Write down each hypothesis and its evidence in the incident channel of the team as the investigation goes
on. The timeline is needed for the postmortem.

## Mitigate, then recover

Prefer the fastest safe mitigation, such as a rollback or a feature flag, over a fix under pressure.
After mitigating:

* Watch the triggering query return to normal. An open incident resolves by itself when the rule meets
  its recovery condition; an acknowledged incident waits for someone to select **Resolve**.
* Silence related incidents that only repeat the known problem, with
  [Silence one incident](https://docs.molesignal.com/en-US/alerting/silences.md#silence-one-incident), not the rule itself.
* Move the status page to **Monitoring**, then **Resolved** once the service has stayed healthy.

## Learn from it

Write the [postmortem](https://docs.molesignal.com/en-US/status-pages#postmortems) on the status page incident within days: what
happened, the impact, the timeline, the cause, and the changes that follow. Save it as a draft while
reviewing, and publish it once the incident is resolved. Mole Agent can draft it from the record of the
incident.

Then improve detection with [Insights](https://docs.molesignal.com/en-US/alerting/incidents.md#insights): **Rapid recoveries** and
**Top firing rules** point at noisy rules, and a late page points at a missing or slow rule. See
[Make production alerts actionable](https://docs.molesignal.com/en-US/best-practices/actionable-alerts.md).

## Acceptance criteria

* Every incident had an owner within the ack timeout.
* Customers heard about customer-facing incidents from the status page before asking.
* The postmortem names the cause, the impact, the timeline, and owners for each follow-up.
* Each follow-up for detection is a concrete rule change, tested on real data.

## Related guides

* [Incidents](https://docs.molesignal.com/en-US/alerting/incidents.md)
* [Status pages](https://docs.molesignal.com/en-US/status-pages)
* [Cross-signal correlation](https://docs.molesignal.com/en-US/correlation.md)
* [Set up on-call and notifications](https://docs.molesignal.com/en-US/best-practices/on-call-setup.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.