> ## Content Index
> Fetch the complete content index at: https://blog.jestor.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# How to run incident management and postmortems
- URL: https://blog.jestor.com/incident-management-and-postmortems/
- Published: 2026-09-16T18:54:58.000Z
- Updated: 2026-09-16T18:54:58.000Z
- Author: Bruno Bannach

Good **incident management** separates two jobs that compete for attention: restoring service and understanding what happened. In **Jestor**, the incident record captures the timeline while the response is under way, so the postmortem starts from evidence rather than from recollection.

## Why postmortems produce little

By the time a postmortem happens, the timeline is reconstructed from memory and chat history. Details are wrong, the sequence is uncertain, and the discussion drifts toward who did what.

Actions are agreed, tracked nowhere, and the next incident reveals none of them happened.

What structured handling provides:

- A timeline recorded while events occur
- Clear roles during the response
- A postmortem based on evidence
- Actions tracked as work with owners
- Patterns visible across incidents

## Roles during an incident

| Role          | Responsibility           | Why separate                         |
| ------------- | ------------------------ | ------------------------------------ |
| Incident lead | Coordinates the response | Someone must decide                  |
| Responders    | Investigate and fix      | Needs uninterrupted focus            |
| Communicator  | Updates stakeholders     | Otherwise responders are interrupted |
| Scribe        | Records the timeline     | Nobody remembers afterwards          |

## Step by step to run one

1. **Open the incident record** as soon as one is declared.
2. **Assign the roles explicitly**, particularly the lead and the scribe.
3. **Record the timeline as events happen**, not afterwards.
4. **Keep stakeholder updates separate** from the response channel.
5. **Declare resolution explicitly**, distinct from the postmortem.
6. **Run the postmortem blamelessly**, focusing on conditions rather than people.
7. **Create actions as tracked records** with owners and deadlines.

## Why the scribe role changes the postmortem

Without someone recording as events unfold, the timeline is reconstructed later and everyone remembers a slightly different sequence. A scribe costs one person's attention during the incident and is what makes the postmortem an analysis rather than a discussion about what probably happened.

## Why choose Jestor

In **Jestor**, an incident is a record where the timeline can be captured as it happens, roles are fields rather than assumptions, documents attached hold the postmortem, resulting actions become connected records with owners and deadlines, and grouping by cause across incidents reveals patterns.

## Frequently Asked Questions

### Why do postmortem actions rarely happen?

Because they are agreed in a meeting and tracked nowhere. See [jestor.com](https://www.jestor.com/?ref=blog.jestor.com).

### Why is a scribe needed during an incident?

Because a timeline reconstructed afterwards is unreliable, and it is the basis of the analysis.

### Should communication be handled by a responder?

No. Separating it keeps responders focused on restoring service.

## Video Tutorial: Step by Step

With **Jestor**, you can automate workflows, connect teams, and build internal systems your way, all without code and powered by **AI**. Discover Jestor at [jestor.com](https://www.jestor.com/?ref=blog.jestor.com) and see how to take your company's operations to a new level of efficiency and control.