True Causes
EN
Bahasa IndonesiaDanskDeutschEnglishEspañolFrançaisItalianoNederlandsNorskPolskiPortuguêsSrpski (latinica)SvenskaTiếng ViệtTürkçeΕλληνικάРусскийСрпски (ћирилица)Українська中文日本語한국어
← lobby
7/7 · Actions
30 people · 30 ideas
walkthrough · not counted
obstacles · anyone with the link · listed publicly · federation on
stewarded by its steward (sealed)
30 people · 30 ideas · 2 groups
Passport → · Logic → · record
↗ share this map
On another site, as a live map:
As a picture: https://truecauses.org/d/6708d57/map.svg
As data: every judged pair in this room (CSV). Each claim has its own address, /c/6708d57/<card>, listed under the map.
Credit when you publish: Causal map: True Causes, https://truecauses.org/d/6708d57
THE QUESTION

Why does the same outage keep recurring?

Propose what to do, then judge whether each action would move each root.

Sealed 23 days ago: this room no longer knows who sat in it; only its steward is still named. What it concluded stays.
30 at the table (29 simulated) · 3 actions proposed against 6 root causes. Add one, then judge whether each action moves each cause.
Viewing as guest. Enter a handle to join and take part.
close ✕
PROPOSED ACTION
Reserve one engineer-week per sprint for post-mortem actions, first in the sprint, not last
Nothing said yet.
Score the roots first
why
The method's own practice, before any action is proposed: each root cause is scored 1–5 on how feasible it is to address, how much impact addressing it would have, and how likely it is to resolve by itself with no intervention. Priority goes to roots with high impact, high feasibility and low likelihood of fixing themselves — priority = impact + feasibility − likelihood. Scores are averaged across the group and shown with how many scored.
1 = low, 5 = high. Your own scores; the group's averages beside them.
root causefeasibleimpactfixes itselfpriority
The service map in the wiki is two years old––––
One engineer knows how the payment path actually works––––
Feature flags are never cleaned up, so nobody knows which paths are live––––
The on-call rota has the same two people on it most weeks––––
Rollbacks take longer than the outage they are meant to end––––
Alerts fire so often that on-call mutes them––––
Would each action move each root cause?
Down the side: the actions people proposed. Across the top: the root causes the map found. Every square is one vote on one question — would this action significantly reduce that cause? One side has to reach 75% of the votes cast to settle it; short of that the square stays split. Each square shows how its votes fell — yes / worse / no — and a square is settled when one of those reaches three quarters of them.
why
Answered at 75% of votes cast, like every other question here. Split means people voted and neither side reached that bar — it is a result, not a queue, and it stays split until enough people change their minds. A square nobody settles stays undecided; it never turns into a no. Judging each pair on its own is what stops a popular action being credited with fixing things it does not touch.
ACTIONROOT CAUSES · does the action on the left reduce it?
The service map in the wiki is two years oldOne engineer knows how the payment path actually worksFeature flags are never cleaned up, so nobody knows which paths are liveThe on-call rota has the same two people on it most weeksRollbacks take longer than the outage they are meant to endAlerts fire so often that on-call mutes them
No production deploy after 14:00 on Fridays unless the on-call engineer agrees discuss✗ no, it does not
3 yes / 0 worse / 26 no
⚑ the group split
21 yes / 0 worse / 8 no
not decided yet
not decided yet
not decided yet
not decided yet
Give the shared schema one named owner and a migration tool with rollback discuss✗ no, it does not
6 yes / 0 worse / 23 no
✓ yes, it reduces this
24 yes / 0 worse / 5 no
not decided yet
not decided yet
not decided yet
not decided yet
Reserve one engineer-week per sprint for post-mortem actions, first in the sprint, not last in focus ↑ · close ✕✗ no, it does not
4 yes / 0 worse / 25 no
✗ no, it does not
3 yes / 0 worse / 26 no
not decided yet
not decided yet
not decided yet
not decided yet
Highest leverage so far
Give the shared schema one named owner and a migration tool with rollback reduces 1 of 6 root causes
THE ACTIONS ON THE MAP
Showing every action the room judged: it acts directly on 1 of the 6 root causes. It does not act directly on 5.
Read from the squares the room settled at Actions, nothing else. A root in green is reduced by at least one of the shown actions; in grey, none of them acts on it directly; a red outline means one of them makes it worse.
Share this view: as a picture · as a live map for another site
The same three services cause most of the pages → The staging environment does not resemble productionFeature work always outranks reliability work in planning → Post-mortem actions are written up and then never scheduledRollbacks take longer than the outage they are meant to end → Reliability has no budget line of its ownEvery team has its own logging format → Customers report outages before monitoring doesReliability has no budget line of its own → The incident channel fills with people asking for status instead of giving itReliability has no budget line of its own → The staging environment does not resemble productionPost-mortems assign actions to people who were not in the room → Post-mortem actions are written up and then never scheduledTests that fail intermittently are retried until green → Customers report outages before monitoring doesRetries are unbounded, so a slow dependency becomes a flood → The same three services cause most of the pagesAlerts fire so often that on-call mutes them → Every team has its own logging formatThe on-call rota has the same two people on it most weeks → Post-mortem actions are written up and then never scheduledThe on-call rota has the same two people on it most weeks → Alerts fire so often that on-call mutes themFeature flags are never cleaned up, so nobody knows which paths are live → The same three services cause most of the pagesFeature flags are never cleaned up, so nobody knows which paths are live → Rollbacks take longer than the outage they are meant to endOne engineer knows how the payment path actually works → The on-call rota has the same two people on it most weeksThe service map in the wiki is two years old → Feature flags are never cleaned up, so nobody knows which paths are liveFeature work always outranks reliability work in planningFeature work alwaysoutranks reliability workin planningPost-mortems assign actions to people who were not in the roomPost-mortems assign actionsto people who were not inthe roomTests that fail intermittently are retried until greenTests that failintermittently are retrieduntil greenRetries are unbounded, so a slow dependency becomes a floodRetries are unbounded, so aslow dependency becomes afloodOne engineer knows how the payment path actually works ② Give the shared schema one named owner and a migration tool with rollbackOne engineer knows how thepayment path actually works②what the shown actions do to this root causeREDUCED BY 1 ACTIONThe service map in the wiki is two years oldThe service map in the wikiis two years oldwhat the shown actions do to this root causeNO ACTION ACTS ON ITDIRECTLYFeature flags are never cleaned up, so nobody knows which paths are liveFeature flags are nevercleaned up, so nobody knowswhich paths are livewhat the shown actions do to this root causeNO ACTION ACTS ON ITDIRECTLYThe on-call rota has the same two people on it most weeksThe on-call rota has thesame two people on it mostweekswhat the shown actions do to this root causeNO ACTION ACTS ON ITDIRECTLYRollbacks take longer than the outage they are meant to endRollbacks take longer thanthe outage they are meantto endwhat the shown actions do to this root causeNO ACTION ACTS ON ITDIRECTLYAlerts fire so often that on-call mutes themAlerts fire so often thaton-call mutes themwhat the shown actions do to this root causeNO ACTION ACTS ON ITDIRECTLYThe same three services cause most of the pagesThe same three servicescause most of the pagesPost-mortem actions are written up and then never scheduledPost-mortem actions arewritten up and then neverscheduledReliability has no budget line of its ownReliability has no budgetline of its ownEvery team has its own logging formatEvery team has its ownlogging formatThe incident channel fills with people asking for status instead of giving itThe incident channel fillswith people asking forstatus instead of giving itThe staging environment does not resemble productionThe staging environmentdoes not resembleproductionCustomers report outages before monitoring doesCustomers report outagesbefore monitoring does
Each number on the map marks a root cause that action reduces.
① No production deploy after 14:00 on Fridays unless the on-call engineer agrees
② Give the shared schema one named owner and a migration tool with rollback
③ Reserve one engineer-week per sprint for post-mortem actions, first in the sprint, not last
What we expect to follow
Predictions about the actions: what each should change, how to measure it, and when to check. On the date, someone who was in the room writes what actually happened beside it.
why
A map says which actions move which causes. It does not say whether anyone did them, or whether anything changed. An entry here is a prediction with a date and something to measure, written after the map settled. When the date comes, what actually happened is written beside it and the prediction stays as it was: a wrong one is the useful kind. Nobody voted on any of this and it changes nothing the room found.
due 23 Jan 2027
actionNo production deploy after 14:00 on Fridays unless the on-call engineer agrees
we expectthe same cause stops coming back once fixing it is in the sprint
measured byrepeat outages with the same cause, per quarter
guessesthe room: 3 (median of 15, spread 1 to 6)