Phased cycle time
Cycle time is split into four stages so you can see which part of the pipeline is slow:
Shown as a stacked bar at the team level and on each engineer’s own detail page as a self-view. A long pickup stage points to reviewers not getting to work; a long review stage points to back-and-forth on changes.
The first-commit stage relies on first-commit data, which fills in as PRs are re-synced — newly tracked repos populate it gradually.
Industry reference bands
The coding, pickup, and review stages carry a small “industry” chip classifying your value against openly published benchmarks — LinearB’s 2026 Software Engineering Benchmarks Report (8.1M+ pull requests across 4,800 teams), with the source and full thresholds in the chip’s tooltip. Where DevPerform’s stage definitions differ slightly from theirs, the tooltip says so and the comparison reads conservatively. The Team Dashboard’s unreviewed-merges stat carries a similar published guideline (fewer than 5% of PRs bypassing review). These are context, not grades — your own trend matters more than any threshold.Review health
Two signals on the Team Dashboard surface review-process risk:- Unreviewed merges — the count and percentage of merged PRs that shipped with zero reviews. A rising number is a quality/risk signal.
- Review depth — the median number of comments per merged PR. Very low depth can mean rubber-stamping; this is a process signal, never a per-person score.
Trends
The Trends view plots weekly throughput (PRs opened and merged) and median cycle time over time, so you can see whether a change is an improvement or just noise. Trends can be scoped to a team.Reading these together
A healthy pattern is short, stable cycle time with consistent review depth and few unreviewed merges. When cycle time spikes, the phased breakdown tells you which stage moved, and the executive view flags the week-over-week jump automatically.Phased cycle time and review health are part of the Growth plan and up. See Plans.