What needs to be finished first
A timeline of the target incident and at least two similarly suspicious prior incidents exist, with date, location, participants, impact, and suspected causes.
What needs to be ready before start
Whiteboard or diagram tool (draw.io, Miro, FigJam) with family tree layout (target incident at bottom, ancestors above); incident database extract or postmortem archive; comparison table with columns for incident, date, factors, recurrence indicator; pattern tags.
One analyst with RCA experience (lead); one to two participants from target incident; one owner familiar with previous postmortems; optionally a systems reviewer from adjacent area.
Target incident description; list of suspected similar incidents from the last 3-24 months; postmortem archive or incident tracker; common tags or categories.
2-4 h
Target incident as root node at bottom. Empty parent rows above. Prepare pattern tags (e.g., deploy-window, cron-conflict, dependency-drift). Keep comparison table on second sheet.
The one question this method answers
Which earlier or parallel incidents form a family with the target incident, and what systemic patterns become visible through that relationship?
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Target incident as anchor | 20-30 min | Set target incident as root: symptom, trigger, contributing factors, affected components. Add tags (for example, payment, retry-loop, deploy-window). Limit to maximum 5 characteristic factors. | If target incident cannot be compressed into five factors, it is a multi-event incident and should be split into multiple trees. |
2Phase 2: Search parent generation | 30-45 min | Search incident archive for incidents with overlapping tags. For each candidate check common factors, time distance, owner, component. Require at least 2-factor overlap as parent criterion. | Including all similar incidents as parents dilutes the picture. Keep entry criteria strict: at least two overlapping factors; otherwise classify as sibling or cousin. |
3Phase 3: Add ancestor generations | 30-45 min | Find parents for each identified parent. Limit to three generations, otherwise tree becomes unreadable. Mark cross-generational connections as dashed lines. | If connections are still found in third generation, this often indicates a systemic cause reproducing for years. That is the most valuable finding. |
4Phase 4: Name patterns | 30-45 min | Mark recurring cross-generational factors (e.g., always Friday deploys, always Service X, same on-call handover). For each pattern, name a cause and reach (how many incidents). | Patterns are not correlations. For each pattern, explain mechanism. Without mechanism, pattern is only statistics. |
5Phase 5: Systemic actions | 30-45 min | For each pattern, define systemic action. Not incident-specific, but for entire pattern. Assign owner with mandate beyond a single service. Success metric: pattern no longer appears in future trees. | Actions at single-service level treat symptoms. If the pattern is "Friday deploys," a freeze on that day addresses the family. |
What comes out at the end
Family tree diagram (3 generations) plus comparison table with factors matrix, identified patterns with mechanism and reach, systemic actions with owner and deadline. Complements classic postmortems.
Date and target incident in header. For later similar incidents, add new root with link to existing tree, or extend existing tree. Keep pattern list as a living document.
Compact working template for Family Tree Analysis with context, input, output artifacts, and next step.
What is this method used for?
Which question should be answered at the end?
Which data, observations, or materials are available?
Owner, date, success signal.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
Root (target incident): 14.05. 09:12 UTC, 8% Order API HTTP 500, connection pool saturated by a new batch job. Tags: connection-pool, batch-job, friday-deploy.
Parents (generation 1):
Grandparents (generation 2):
Patterns:
Systemic actions:
Recognize symptoms and steer against them
Tree includes 15 incidents over 2 years, common factors are generic (all in production).
Use at least two overlapping factors as parent criterion. Generic tags such as production or live do not count. Better a smaller but specific tree.
A pattern is named, but no one explains why that factor repeats.
For every pattern, require mechanism: why does this factor reproduce? Without mechanism, pattern is only repetition.
Recommendations address only the target incident, pattern persists.
Actions must affect the whole pattern, not just one instance. Success criterion: pattern does not recur in next 12 months.
Tree has 6+ generations; no one can interpret it.
Limit to maximum 3 generations. Older predecessors belong in appendix or separate tree analysis. Visualization should stay interpretable.
Postmortem data only goes 6 months back; older incidents unavailable.
Document limitation. Work with available depth, but add recommendation to establish postmortem archive.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.