RunsheetOperations

Root Cause Tree Analysis

ComplexityMedium

Time1-3 h

Participants2-8

FormatWorkshop

MaturityEstablished

Prerequisite

What needs to be finished first

Complete firstIncident Timelinenot in catalog

A chronological record of symptoms, logs and actions is available.

Without: Without timeline, branches in the tree cannot be evidenced and hypotheses collapse into speculation.

Complete firstBlameless Postmortem

The group works in blameless mode so causal paths are pursued systemically and not personally.

Without: Without this norm, group narrows paths too early and stops at human errors instead of mechanisms.

Preparation

What needs to be ready before start

Materials

Whiteboard or Miro board with root node at top (problem); pens; sticky notes in three colors (hypothesis, evidence, action); access to logs, metrics, configurations; timer.

People / roles

One facilitator who guides branching and asks for evidence; three to eight participants with system contact; one scribe for evidence column; if needed one data operator who runs live queries.

Pre-read

Problem sentence with timestamp and impact; known workarounds; available data sources; incident ID; list of suspected causes from group gut feeling.

Time needed

1-3 h

Setup

Fix problem sentence at top of board. Prepare three vertical zones (level 1, 2, 3) for branching depth. State rule: every hypothesis needs evidence, every path ends either at controllable cause or unverified assumption.

Core question

The one question this method answers

Which causal paths lead from observed problem to controllable causes, and which actions address the most likely paths?

Flow

Marker: Phase

Step	Duration	Action	Hint
1Phase 1: Formulate problem precisely	10-15 min	Write problem as observable symptom in one sentence: what, when, how often, which effect. No cause in sentence. Formulate success picture for analysis.	If sentence contains "because X", diagnosis is already made and tree no longer works. Reformulate.
2Phase 2: Branch causes	30-60 min	One branch per possible cause. On level 1, main categories (for example software, data, infrastructure, process). On levels 2 and 3, concrete hypotheses.	Require at least three main branches, otherwise tree becomes one-sided. If a branch remains empty, explicitly mark as consciously empty with rationale.
3Phase 3: Add evidence	30-45 min	Stick yellow evidence note per hypothesis: log, graph, config line or test result. If no evidence available, red unverified note and spike task.	Evidence is checked live during session where possible. With operator present, many hypotheses can be refuted or confirmed immediately.
4Phase 4: Prioritize and actions	20-30 min	Rate paths by probability and leverage (for example traffic light). Concrete action with owner and date per top path. Explicitly separate detection actions from cause correction.	Improving monitoring is detection, not cause correction. Note both, clearly separated.

Artifact

What comes out at the end

Form

Cause tree diagram as image plus structured markdown with problem sentence, hierarchical list of all paths, evidence per hypothesis, rating and concrete actions with owner and date.

Versioning / ownership

Own entry per incident with date and incident ID. Later findings as update section at end; do not delete falsified paths, mark as refuted with evidence.

Tool alternatives

Miro with Cause Tree template
Whiteboard with photo export
draw.io or Excalidraw with tree layout
Markdown with indented hierarchy in incident repo

root-cause-tree-analysis-working-template.md

Compact working template for Root Cause Tree Analysis with branching causes, evidence, and countermeasures.

Root Cause Tree Analysis Working Template

Goal

Trace a problem into branching causes until the most likely root causes become visible.

Context

Which problem should the group analyze, and what evidence is available?

Input

Problem statement:
Observations:
Data or logs:
Known constraints:

Working area

Branch 1:
Branch 2:
Branch 3:
Evidence and uncertainties:
Likely root causes:

Output artifacts

Cause tree:
Evidence notes:
Countermeasures:

Open questions

Decision / next step

Owner, date, and success signal.

Example output

Concrete filled scenario, fictional example

root-cause-tree-analysis-beispiel.md

Concrete filled scenario, fictional example

Cause Tree - Increased 5xx Rate Order API (2026-05-14)

Problem: Order API has returned HTTP 500 for around 8% of checkout requests since 2026-05-14 09:12 UTC.

Paths (excerpt):

Software
- Recent deploy (evidence: deploy 09:05 from feature/order-validation, RED - no direct error in logs)
- Library update (evidence: no updates in 48 h, EXCLUDED)
Data
- DB pool utilization (evidence: Grafana shows pool 100% since 09:10, CONFIRMED)
  - New batch job (evidence: cron ran first time 09:10, CONFIRMED - root cause)
Infrastructure
- Network latency (evidence: P50 stable, EXCLUDED)

Actions:

Cause correction: dedicated connection pool for batch (Owner: @anna, by 2026-05-21).
Detection: alert on pool utilization above 80% for 2 min (Owner: @ben, by 2026-05-18).

What to do

Track detection and cause correction separately. Per identified cause, at least one action that prevents recurrence, not only increases visibility.

Stop criteria

Done signals checkable in under a minute

No data access available, evidence remains speculation throughout.

Symptom is not reproducible or one-off, tree cannot be tested.

No person with system contact present, hypotheses are hearsay.

Workshop scheduled under 60 min, four phases cannot be run.

Problem is trivial (known fix), tree creates only bureaucracy.

Group refuses to open alternative paths, analysis becomes one-sided.

Finished the runsheet?

Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.

Go to profile More methods