What Are Bus Factor?
The minimum number of team members who would need to leave (or be unavailable) before a project or area of the codebase would stall due to knowledge loss.
2-minute setup • No credit card required
What it means
Bus factor quantifies knowledge concentration risk on a team. A bus factor of 1 means one person holds critical knowledge that no one else has — if they leave, go on vacation, or get sick, that part of the project stalls. A bus factor of 3 means three people would need to be unavailable simultaneously to cause a stall. The name comes from the morbid hypothetical 'what if someone got hit by a bus?' but in practice it applies to any form of unavailability: resignation, vacation, parental leave, or simply being pulled onto another project. Bus factor can be measured per repository, per service, or per area of the codebase. Git data is useful here: if only one person has committed to a service in the last 6 months, that service has a bus factor of 1 regardless of how many people could theoretically work on it.
Why Bus Factor matter
Low bus factor is one of the most common and most dangerous risks in engineering teams, and it's invisible until it strikes. When the sole expert on the billing system quits, the team discovers they can't debug billing issues, don't understand the deployment process, and have no documentation. This can take weeks or months to recover from. For engineering managers, bus factor maps directly to planning risk: a bus factor of 1 on your critical path means your project timeline depends on one person's availability. For CTOs, low bus factor across multiple systems is a systemic organizational risk. Improving bus factor through code review, pair programming, rotation, and documentation is one of the highest-leverage investments a team can make.
How to measure
Analyze git history to find how many unique contributors have committed to each repository, service, or directory in the last 3-6 months. A contributor who made only 1-2 trivial commits doesn't meaningfully reduce bus factor — look for contributors with substantial, recent commits across different areas of the code. Tools like Gitmore and git-fame can generate these reports automatically. The simplest calculation: for each repo/service, count the number of active contributors in the last quarter. Services with 1-2 contributors are high-risk.
Real-world example
An engineering manager runs a bus factor analysis across their 12 microservices. They find that 4 services have a bus factor of 1: the payment processor (only Sarah has committed in 6 months), the notification system (only James), the data pipeline (only Alex), and the admin dashboard (only Maria). They implement a rotation: each quarter, one engineer spends 2 weeks doing meaningful work on a service they don't own, with the owner available for pairing. After two quarters, all 12 services have a bus factor of at least 3.
Related terms
Common questions
What is a healthy bus factor?
At minimum 2 for every critical system, ideally 3+. A bus factor of 1 is an immediate risk that should be addressed. For mission-critical systems (authentication, payments, core data pipeline), aim for a bus factor of 3-4. For less critical systems, 2 is acceptable.
How do you increase bus factor?
Five approaches: (1) Rotate engineers across services — have someone spend 1-2 sprints working on an unfamiliar service, (2) Pair programming on complex areas, (3) Code review by people outside the service's primary team, (4) Document architecture decisions and operational runbooks, (5) Share on-call responsibility so multiple people learn incident response for each service.
Does documentation alone fix bus factor?
No. Documentation helps but isn't sufficient. A developer who has only read documentation about a service is not as capable as someone who has actually worked on it, debugged issues, and deployed changes. Documentation reduces ramp-up time but doesn't replace hands-on experience. The most effective approach combines documentation with actual work rotation.
Can you measure bus factor from git data?
Yes, approximately. Count unique contributors per repository or directory over the last 3-6 months, weighted by the significance of their contributions. A developer who merged 50 PRs touching core logic is a stronger contributor than one who fixed a typo. Git analytics tools can automate this analysis and flag repositories with dangerously low bus factors.
Track Bus Factor Automatically
Gitmore turns your git activity into automated reports with real metrics — delivered to Slack and email.
Get Started FreeNo credit card • No sales call • Reports in 2 minutes