GUIDE
Team Health Metrics: Toil, Bus Factor and More Explained
Toil ratio, bus factor, rework rate and cancellation rate — signals about how sustainable a team's pace actually is, not just how fast it ships.
Why these aren't DORA or Flow metrics
DORA metrics describe the delivery pipeline; Flow metrics describe how work moves through a team. Neither one answers a different, equally important question: is the way a team hits those numbers sustainable, or is it quietly running on unsustainable practices that will show up as a problem later — burnout, a single person the whole team secretly depends on, work that gets thrown away after real effort went into it. These signals don't come from one unifying framework the way DORA (DORA Research/Google Cloud) or Flow metrics (the Flow Framework) do — some, like bus factor, are decades-old engineering terms; others are more specific to how moasy.tech looks at a team's day-to-day health. What they share is the same purpose: catching a problem in how work gets done, not just measuring what got done.
The core team health signals
| Signal | What it measures | Why it matters |
|---|---|---|
| Toil Ratio | Share of this month's capacity spent on recurring operational work. | High toil crowds out the work that actually moves a product forward. |
| Bus Factor | How concentrated work is on one or two people. | A team that depends entirely on one person is one absence away from a real problem. |
| Rework & Review Health | How much shipped code gets rewritten soon after, and how thoroughly PRs get reviewed. | Both are early signals of quality problems, well before they surface as incidents. |
| Cancellation Rate | Share of work that gets abandoned instead of delivered. | High cancellation usually points to a scoping problem, not an execution one. |
Why teams track them
A team can look excellent on every DORA and Flow number while quietly heading toward a burnout problem, a bus-factor crisis, or a quality issue that hasn't surfaced as an incident yet — these signals exist because delivery speed alone doesn't reveal any of that. They're deliberately less about output and more about how the work gets done: is it one person carrying the load, is "done" actually staying done, is the team spending its capacity on the work it means to be spending it on.
How teams usually track them manually (and where it gets messy)
Some of this shows up informally long before anyone measures it — "only Maria understands the billing service" is a bus factor observation nobody wrote down. Making it a number instead of a hallway comment is where it gets hard by hand: toil needs hours tracked against team capacity, not just a gut feeling; review health needs pull request history parsed for who reviewed what; cancellation rate needs a workflow that actually tracks "abandoned" as different from "done" in the first place, which most issue trackers don't distinguish by default.
How moasy.tech computes it automatically
moasy.tech recalculates all four signals from what's already synced from Jira, Linear, GitHub and Azure DevOps — read-only, no manual survey or spreadsheet. Toil ratio uses the same configurable category rules as Flow Distribution; bus factor and review health come straight from PR and work-item history; cancellation rate depends on a genuine "cancelled" state, distinct from "done," so abandoned work stops quietly inflating delivery numbers. No AI in the pipeline — every number is a direct calculation.
See each signal in detail: Toil Ratio, Bus Factor, Rework & Review Health, and Cancellation Rate, or the complete implementation on the Capacity & Workload feature page.
Illustrative data, for demonstration purposes only.
Questions about team health metrics
Are these used to rank or evaluate individual people?
No — every one of these is a team-level or work-level signal (capacity, concentration, review practice, scoping), not an individual performance score. Bus factor in particular is about a team's dependency structure, not about which person is "better."
Do I need all four to get value from any one of them?
No — each is useful on its own, though they're often read together. A team investigating quality issues might start with rework and review health; one worried about resilience might start with bus factor.
Is there an official source for these, like DORA's State of DevOps Report?
Not a single one — bus factor is a long-established engineering term with no single owner; the others are closer to common engineering-management practice than a published research program. Treat the concepts as industry-standard, not a specific benchmark tied to one report.
See your own team health metrics
Get started free