> ## 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 a Post-Mortem on a Failed Process
- URL: https://blog.jestor.com/post-mortem-on-failed-process/
- Published: 2026-09-17T22:33:44.000Z
- Updated: 2026-09-17T22:33:44.000Z
- Author: Bruno Bannach

A **post-mortem on a failed process** is only useful if it establishes what happened rather than what people remember happening. Recollection produces blame; data produces changes.

## Why post-mortems go badly

Without evidence, the discussion becomes about people.

- Accounts differing depending on who is telling them
- The loudest explanation accepted as the cause
- Conclusions that cannot be acted on
- The same failure recurring months later

## What to establish, in order

| Question                       | Where the answer lives                       |
| ------------------------------ | -------------------------------------------- |
| **What changed, and when?**    | Table history, filtered by date and source   |
| **Where did it wait?**         | SLA dwell time per stage                     |
| **Was a step skipped?**        | Stages with near-zero dwell time             |
| **Did an automation act?**     | Execution log and the history's source field |
| **Who could have changed it?** | Role and permission configuration            |

## How to investigate in Jestor

1. Open the table history in **Jestor** and filter by date to the period in question.
2. Filter by source to separate user edits from automation and **API** changes.
3. Review the record's **SLA** data to see where it waited or which stage it skipped.
4. Check the automation execution log for anything that fired or failed to.
5. Export the filtered history so the findings are documented rather than recalled.

## Why choose Jestor for incident investigation?

**Jestor** records the source of every change, so a record that moved unexpectedly can be traced to what moved it rather than debated.

Because changes saved together are grouped with their full before-and-after state, the sequence of events is reconstructable rather than inferred.

## Frequently Asked Questions

### Can I tell whether an automation caused it?

Yes, by filtering the history by source. See [jestor.com](https://jestor.com/?ref=blog.jestor.com).

### Can I see the previous values?

Yes, the before-and-after state is recorded.

### Can I document the findings?

Yes, by exporting the filtered history.

## Video Tutorial: Step by Step

Check out other practical tutorials on the Jestor YouTube channel.

## Get to know Jestor

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://jestor.com/?ref=blog.jestor.com) and see how to take your company's operations to a new level of efficiency and control.