GUIDE
Bus Factor: What It Measures and Why It Matters
How many people would need to disappear before a team can't function — measured as contribution concentration, without naming who carries the risk.
What it measures
"Bus factor" is a decades-old engineering term (the grim version asks how many people would need to get hit by a bus before a project stalls) for how concentrated critical knowledge or output is on a small number of people. moasy.tech measures a practical proxy for it — contribution concentration: the share of a team's work items or pull requests carried by its single most active contributor, over a chosen period. A team where one person accounts for 60% of merged PRs has a low bus factor — most of the team's momentum runs through one person — even if everyone on the roster is nominally "on the team."
Why it matters
A low bus factor doesn't show up as an incident until the moment it does — someone goes on leave, gets pulled onto another project, or leaves the company, and suddenly the team discovers that only one person actually understood the billing service, or that only one person's reviews were ever really trusted to merge. By then it's a crisis, not a planning conversation. Measuring concentration turns an informal, half-known risk ("yeah, Maria's really the only one who gets that part of the codebase") into a number that can be acted on ahead of time — pairing, review rotation, documentation — while it's still cheap to fix.
How to calculate it
Count each contributor's share of work items completed (or PRs merged) over the period, and take the largest single share as the team's contribution concentration.
A worked example: a 6-person team merges 50 PRs in a month. If one person merged 28 of them, that's 28/50 = 56% concentration — over half the team's shipped work moved through a single person. A team where the same 50 PRs were spread with no one above 20% has a much healthier bus factor, even with the same total output.
How to interpret the numbers
There's no industry-published "safe" concentration percentage the way DORA has an elite/typical band — team size, role specialization, and how new the team is all shift what's normal. A 2-person team will always show higher concentration than a 10-person one by simple arithmetic; what's worth watching is concentration that's high and rising on a team large enough that it shouldn't be, or concentration on a specific critical area of the codebase rather than the team overall.
A common trap
It's tempting to read high concentration as "that person is carrying the team" and treat it as a compliment rather than a risk. Both readings can be true at once — the person may well be doing excellent work, and the team may still be one absence away from a real problem. The number isn't a judgment on the contributor; it's a structural signal about how much the team's resilience depends on one person staying available.
How moasy.tech computes it
moasy.tech recalculates contribution concentration from synced work-item and pull-request history — no manual survey, no "who knows this system" workshop. The metric deliberately never names the contributor on the team-wide view: it surfaces the percentage and sample size, framed as a conversation starter rather than a leaderboard. The same synced history also feeds rework and review health, since both draw on the same pull-request data.
See the full implementation on the Capacity & Workload feature page, or back up to Team Health for the other signals in this cluster.
Illustrative data, for demonstration purposes only.
Questions about bus factor
Does this name who the top contributor is?
No — the team-wide view shows only the percentage and the sample size (items or PRs), by design. It's meant to flag a risk worth discussing, not to point at a person.
Is a small team automatically going to look risky?
It will often show higher concentration by simple arithmetic — with fewer people, any one person's share is naturally larger. Read the number relative to team size, not as an absolute threshold shared across every team.
Is this the same thing as "10x engineer" tracking?
No — it says nothing about the quality or difficulty of any one person's work, only how much of the team's total output is concentrated on them. High output from one strong contributor and high risk from over-reliance on that same person are two different conversations that happen to produce a similar-looking number.
See your own team's bus factor
Get started free