True Causes
EN
← lobby
7/7 · Actions · viewing Cluster
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?

Group cards you judge alike. Groups organise reading; they decide nothing.

closed · back to Actions
Viewing as guest. Enter a handle to join and take part.
Clusters form from similarity, names come last
Canonical order: link pairs of ideas you judge similar — links are symmetric (A~B is B~A; direction never matters) and a tie holds once 2 members make it.
why
Links are symmetric — A~B is B~A. Clusters are the groups that emerge from held ties, and only a formed cluster can be named, by a person. Your own links carry a ✕ to withdraw; you cannot remove someone else's. Clusters organise the wall and never gate the vote — two cards making the same CLAIM are a merge back in Clarify.
Links and names are made while Cluster is live; the steward’s ← reopens it.
close ✕
Nobody owns the shared database schema
To be precise: this is about the process, not the person on call that night.
Nothing said yet.
unnamed cluster — name it if the group has a common thread, or leave it unnamed (2)
Alerts fire so often that on-call mutes them
~ Customers report outa…Customers report outages before monitoring does (12)
discuss
Customers report outages before monitoring does
~ Alerts fire so often …Alerts fire so often that on-call mutes them (12)
discuss
unnamed cluster — name it if the group has a common thread, or leave it unnamed (2)
The same three services cause most of the pages
~ The on-call rota has …The on-call rota has the same two people on it most weeks (20)
discuss
The on-call rota has the same two people on it most weeks
~ The same three servic…The same three services cause most of the pages (20)
discuss
unnamed cluster — name it if the group has a common thread, or leave it unnamed (2)
Every team has its own logging format
~ Reliability has no bu…Reliability has no budget line of its own (15)
discuss
Reliability has no budget line of its own
~ Every team has its ow…Every team has its own logging format (15)
discuss
unnamed cluster — name it if the group has a common thread, or leave it unnamed (2)
Runbooks are out of date within a month of being written
~ The service map in th…The service map in the wiki is two years old (16)
discussing (1)
The service map in the wiki is two years old
~ Runbooks are out of d…Runbooks are out of date within a month of being written (16)
discuss
unnamed cluster — name it if the group has a common thread, or leave it unnamed (2)
Post-mortem actions are written up and then never scheduled
~ Post-mortems assign a…Post-mortems assign actions to people who were not in the room (9)
~ Feature flags are nev…Feature flags are never cleaned up, so nobody knows which paths are live (14)
discuss
Feature flags are never cleaned up, so nobody knows which paths are live
~ Post-mortem actions a…Post-mortem actions are written up and then never scheduled (14)
discuss
unnamed cluster — name it if the group has a common thread, or leave it unnamed (2)
Config lives in five places and drifts between them
~ Migrations are run by…Migrations are run by hand from a laptop (21)
discuss
Migrations are run by hand from a laptop
~ Config lives in five …Config lives in five places and drifts between them (21)
discuss
· not yet clustered (18)
Tests that fail intermittently are retried until green
Leadership asks for a root cause within the hour, so the first plausible one wins
Success is measured in features shipped per quarter
Dependencies are upgraded only when something breaks
Deploys go out on Friday afternoons because that is when the sprint ends
Rollbacks take longer than the outage they are meant to end
Post-mortems assign actions to people who were not in the room
~ Post-mortem actions a…Post-mortem actions are written up and then never scheduled (9)
discuss
Feature work always outranks reliability work in planning
There is no time set aside after an incident, so the write-up is done at midnight
Incidents are declared late because declaring one feels like blame
Load tests were last run before the customer base doubled
One engineer knows how the payment path actually works
Error budgets exist on a slide and nowhere else
The staging environment does not resemble production
The incident channel fills with people asking for status instead of giving it
Nobody owns the shared database schema
Retries are unbounded, so a slow dependency becomes a flood
Capacity is added after the outage, never before