A bus factor audit is not a documentation project. It is a mapping exercise. The deliverable is a per-service list of people who can actually restart the service, plus the evidence behind each name. If the list has names but no evidence, you have a hypothesis, not a map.

For a team of 2–15 engineers who are their own on-call rotation, the audit has one job: find the services where the answer to “who can restart this?” is a single person, a stale runbook, or a name that has never done it under pressure. Then turn those gaps into drills, shadowing, and runbook work before the next incident finds them for you.

Why this is a mapping exercise, not a documentation project

Documentation projects tend to produce artifacts that describe how a service works. A bus factor audit produces a different artifact: a table that says who can perform a specific recovery action and how you know. The distinction matters because a runbook can be complete and still leave you with a bus factor of one. The runbook is not the capability. The person who has executed the runbook is the capability.

PagerDuty’s incident response guidance notes that knowledge of how to handle incidents is often lost when a team member leaves, which is why a documented process becomes more crucial over time. That is the failure mode the audit is designed to surface before it becomes an incident. The audit does not replace the documentation; it tells you where the documentation is the only thing standing between you and an unowned service.

NIST SP 800-34 Rev. 1 frames contingency planning as a process of evaluating information systems and operations to determine requirements and priorities. A bus factor audit is a narrow, repeatable version of that evaluation, scoped to restart and recovery actions rather than the full contingency plan.

Define the unit of audit: service, restart action, evidence

The unit of work is not the service as a whole. It is the restart action. A single service may have several restart paths, and different people may be able to perform each one:

• Process restart on the primary host or container.
• Failover to a standby or secondary region.
• Restore from backup (database, object store, configuration).
• Rebuild from infrastructure-as-code when the host is gone.
• Break-glass access path when normal credentials are unavailable.

For each path, record the evidence type. Three levels are enough for most lean teams:

• Has done it in an incident. The strongest evidence. The person executed the action under real pressure, with real consequences.
• Has done it in a drill. Strong evidence. The person executed the action in a controlled setting, ideally with a time constraint and a defined success condition.
• Has read the runbook. Weak evidence. This is a starting point, not a qualification.

Google’s SRE workbook describes a pre-on-call checklist that includes administering production jobs, rolling back a bad software push, bringing up additional serving capacity, and using monitoring systems. That checklist is a useful model for the evidence bar: the question is not “have you read about this?” but “have you practiced this?”

Build the map

One row per service. Columns for primary, backup, evidence type, last verified date, and known gaps. Keep it in a place the team already looks at, not a separate tool that will be forgotten.

Service	Restart path	Primary	Backup	Evidence	Last verified	Known gaps
payments-api	Process restart	Engineer A	Engineer B	Incident (2025-08)	2025-08-14	None
payments-api	Restore from pgBackRest	Engineer A	—	Read runbook only	2025-06-02	No second person has executed a restore
internal-tools	Rebuild from Terraform	Engineer C	Engineer D	Drill (2025-09)	2025-09-20	Break-glass path untested

The table is deliberately small. For a 2–15 engineer team, the audit should be completable in a few sessions. If it is taking longer, the scope is too broad. Start with the services that have the highest blast radius and the fewest people.

Use the map to find single points of failure

Three patterns are worth flagging explicitly:

• One name, no backup. The service has a primary but no second person who has executed the restart path. This is the classic bus factor of one.
• Names but no evidence. The service has a primary and a backup, but both are at “has read the runbook.” This is a bus factor of one with extra steps.
• The runbook is the only artifact. No one on the current team has executed the restart path, and the runbook was written by someone who has left. This is the highest-risk category because the runbook may be stale in ways no one can see.

Google’s SRE workbook notes that playbook details go out of date at the same rate as production environment changes, and that for daily releases, playbooks might need an update on any given day. A runbook that has not been executed by a current team member is a runbook whose staleness is unknown.

Turn gaps into drills

The audit’s output should feed directly into drills and shadowing, not into a separate documentation backlog. The goal is to move people from “has read the runbook” to “has done it in a drill.”

Google’s SRE workbook describes the Wheel of Misfortune as a training exercise where teams role-play recent incidents to practice debugging production problems. A bus factor drill is a narrower version: pick a service with a gap, pick a person who has not executed the restart path, and run the restart in a controlled setting. The success condition is not “the service came back” but “the person can describe what they did and why.”

For restore paths, a restore lottery is a useful format. One person is selected at random, given the backup and the runbook, and asked to restore to a point in time. The exercise surfaces both the person’s capability and the runbook’s accuracy. If the restore fails because the runbook is wrong, that is a finding, not a failure.

For services with no second person, shadowing is the first step. The primary executes the restart path while the backup observes and asks questions. The next step is the reverse: the backup executes while the primary observes. Only after that does the backup count as evidence.

Keep the map alive

A bus factor map that is not reviewed becomes a stale spreadsheet. Tie the review to artifacts the team already uses:

• On-call handoffs. When the rotation changes, check whether the new on-call has executed the restart paths for the services they are now responsible for.
• Playbook updates. When a runbook changes, mark the corresponding map row as unverified until someone executes the new path.
• Postmortem action items. When a postmortem identifies a recovery gap, add it to the map with a review date.

The Google SRE book states that an unreviewed postmortem might as well never have existed, and that regular review sessions are encouraged to ensure each completed draft is reviewed. The same logic applies to the bus factor map: an unreviewed map is a map you cannot trust.

Google’s SRE book lists common postmortem triggers including user-visible downtime or degradation beyond a certain threshold, data loss of any kind, on-call engineer intervention, a resolution time above some threshold, and a monitoring failure. Any of these triggers is also a signal to re-check the map for the affected service.

What to do when the map shows a gap you cannot close this quarter

Not every gap can be closed immediately. A team of five engineers cannot train everyone on everything in a single quarter. When a gap cannot be closed, record it explicitly:

• The service and restart path.
• The current evidence level.
• The accepted risk, in plain language.
• A review date.

The alternative is to leave the service silently unowned, which is the condition the audit was meant to find. An accepted risk with a review date is a decision. An unrecorded gap is an accident waiting for a trigger.

For teams running on AWS, GCP, or bare metal, the audit is the same exercise. The AWS Well-Architected Framework reliability pillar notes that achieving reliability can be challenging in traditional on-premises environments due to single points of failure, lack of automation, and lack of elasticity. The bus factor audit is a way to find the human single points of failure that architecture diagrams do not show.

A short, repeatable audit cadence

For a 2–15 engineer team, a quarterly cadence is enough to keep the map current without turning it into a project. The cadence can be as simple as:

1. Pick the three services with the highest blast radius.
2. For each, list the restart paths and the people who can execute them.
3. Mark the evidence level for each person.
4. Identify one gap per service and schedule a drill or shadowing session.
5. Update the map with the drill result and a new review date.

The audit is not a one-time report. It is a working artifact that changes as the team changes. The goal is not to eliminate every gap. The goal is to know where the gaps are, so that when the pager fires at 03:00, the person who answers has a realistic path to recovery.

Frequently asked questions

How is a bus factor audit different from a runbook review?

A runbook review checks whether the documentation is accurate. A bus factor audit checks whether a person can execute the documented steps. A runbook can pass review and still leave you with a bus factor of one if no one on the current team has executed it.

How many people need to be able to restart a service?

There is no universal number. The audit’s job is to make the current state visible, not to enforce a threshold. For a team of 2–15 engineers, the practical question is whether the service has at least one person who can execute the restart path when the primary is unavailable, and whether that person has evidence beyond reading the runbook.

What if the only person who can restart a service is leaving?

That is the highest-priority gap the audit can find. The response is a drill or shadowing session before the person leaves, with the goal of moving at least one other person to “has done it in a drill.” If that is not possible, the gap should be recorded as an accepted risk with a review date and a plan for the next quarter.

Should the audit include break-glass access?

Yes. Break-glass access is a restart path. If the normal credentials are unavailable, the break-glass path is the one that matters. The audit should record who can use it and whether they have tested it.

How often should the map be reviewed?

Quarterly is a reasonable default for a lean team. The map should also be reviewed after any incident that required a restart, after any on-call rotation change, and after any playbook update that changes a restart path.

For a related practice, see Write the Recovery Checklist Before You Need It, which covers the checklist side of the same problem: what to have ready before the restart is needed.