Complete firstIncident timelinenot in catalog
A chronological sequence of events with timestamps is available from the trigger to stabilization.
Without: Without a timeline, the team will mix up sequence and cause and the analysis will drift.
RunsheetOperations
Causal Factor Analysis
ComplexityHigh
Time2-6 h
Participants3-10
FormatWorkshop + async
MaturityEstablished
01
Prerequisite
What needs to be finished first
Complete firstBlameless Postmortem
A blame-free review setting is in place so that people can separate facts, decisions, and interpretations.
Without: Without that norm, the causal review can easily turn into blame and the evidence will get weaker.
02
Preparation
What needs to be ready before start
Materials
Timeline board or incident template; logs, metrics, and ticket history; sticky notes; markers; export or capture tool for the final timeline.
People / roles
One facilitator; one scribe; two to five people with direct process or system knowledge; optionally one reviewer who checks evidence quality.
Pre-read
Incident ID, event window, affected systems, known signals, and any decisions or mitigations that happened during the incident.
Time needed
60-90 min
Setup
Lay out the chronology first. Keep evidence, interpretations, and hypotheses on separate notes. Do not jump to causes before the timeline is visible.
03
Core question
The one question this method answers
Which event factors and conditions actually shaped the incident, and which ones are root causes versus contributors?
04
Flow
Marker: Minute
| Step | Duration | Action | Hint |
|---|---|---|---|
10-10 min | 10 min | Collect the incident facts: timestamped events, alerts, decisions, and visible impact. Keep opinions out of the first pass. | If the first notes already contain explanations, the group is skipping the evidence base. Start with what happened, not why it happened. |
210-25 min | 15 min | Reconstruct the timeline from trigger to stabilization. Add the events in order and mark gaps that still need evidence. | A missing event is still a finding. Mark unknowns explicitly instead of filling them with memory. |
325-40 min | 15 min | Mark causal factors, contributing conditions, and decision points on the timeline. Distinguish triggers from deeper causes. | Not every factor is a cause. If a note only explains context, move it out of the causal column. |
440-55 min | 15 min | Check each proposed factor against logs, metrics, or other evidence. Keep unverified items separate. | Evidence checking is the heart of the method. A plausible story without evidence is still only a story. |
555-90 min | 35 min | Derive the root causes and the follow-up actions. Separate recurrence prevention from detection improvements and assign owners. | Detection fixes are useful, but they do not replace cause fixes. Keep both lists visible so the team does not stop too early. |
05
Artifact
What comes out at the end
Form
An incident timeline, a causal factor chart, a cause list, and a clear action list with owners, evidence notes, and open questions.
Versioning / ownership
Store the incident ID, date, and version state together. Keep evidence updates as later revisions instead of overwriting the original causal chain.
Tool alternatives
- Miro timeline board
- Lucidchart or Whimsical
- Confluence incident page
- Markdown in the incident repo
causal-factor-analysis-working-template.md
Compact working template for Causal Factor Analysis with context, input, output artifacts, and next step.
Causal Factor Analysis Working Template
Goal
Reconstructs events and contributing factors to understand the main causes of a problem.
Context
When and for what do we use this method?
Input
Which data, observations, decisions, or materials are available?
Execution
Short notes along the runsheet.
Output artifacts
- Event Timeline:
- Causal Factor Chart:
- Cause List:
- Corrective Actions:
Assumptions and open questions
- ...
Decision / Next step
Owner, date, and success signal.
06
Example output
Concrete filled scenario, fictional example
causal-factor-analysis-beispiel.md
Concrete filled scenario, fictional example
Causal Factor Analysis — Checkout outage, 14.05.2026
Timeline
- 09:12: first latency spike after deployment 1842.
- 09:18: queue length starts growing.
- 09:25: alert threshold is hit.
- 09:31: rollback begins.
- 09:47: service stabilizes.
Causal factors
- Deployment changed the request path.
- Queue workers were already near capacity.
- Alerting fired late because the threshold was too wide.
Actions
- Add a pre-deploy capacity check, owner: @anna.
- Tighten the queue alert threshold, owner: @leo.
- Review the rollout gate for the next release, owner: @sara.
07
Pitfalls
Recognize symptoms and steer against them
Trap
Timeline is incomplete
Symptom
Important timestamps are missing, so the sequence stays unclear.
What to do
Go back to logs, tickets, and alerts until the main chain is visible. A causal review without sequence is too weak.
Trap
Facts and interpretations are mixed
Symptom
The board contains both observations and explanations in the same column.
What to do
Separate evidence, interpretation, and hypothesis explicitly. That keeps the causal logic readable.
Trap
Contributors are treated as root causes
Symptom
Conditions that shaped the event are listed as if they were the final cause.
What to do
Ask whether the factor triggered the incident, contributed to it, or sat deeper in the system. Only the deepest controllable cause belongs in the root-cause slot.
Trap
The team stops at the symptom
Symptom
The discussion ends with better monitoring or a quick workaround only.
What to do
Split detection improvements from recurrence prevention. A visible symptom fix is useful, but it is not the end of the analysis.
Trap
The review turns into blame
Symptom
People start naming roles or individuals instead of mechanisms.
What to do
Return to evidence and process conditions. If a person is mentioned, ask which safety net, control, or decision path was missing.
08
Stop criteria
Done signals checkable in under a minute
No chronological event sequence is available, so the method has no anchor.
There is not enough evidence to verify the proposed factors.
Only one person witnessed the event and the rest is memory.
The incident is a simple defect without an event chain.
The session is urgent operational response, not a review.
The team cannot keep facts and interpretations separate.
Finished the runsheet?
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.