> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devperform.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Flow & Review Health

> Phased cycle time, review health signals, and weekly trends.

Beyond the single cycle-time number, DevPerform breaks down *where* work spends its time and *how healthy* your review process is.

## Phased cycle time

Cycle time is split into four stages so you can see which part of the pipeline is slow:

| Stage                   | From → to                                                                                                                                                                 |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **First commit → open** | First commit → PR opened. Labeled for exactly what git observes: in commit-then-open workflows (AI agents especially) this gap is seconds — that's real, not missing data |
| **Pickup**              | PR opened → first review (or merge, if never reviewed)                                                                                                                    |
| **Review**              | First review → merged                                                                                                                                                     |
| **Deploy**              | Merged → deployed *(actions mode only)*                                                                                                                                   |

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.

<Note>
  The first-commit stage relies on first-commit data, which fills in as PRs are re-synced — newly tracked repos populate it gradually.
</Note>

### 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.

Both respect the active team filter and date range.

## 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](/dashboard/executive) flags the week-over-week jump automatically.

<Note>
  Phased cycle time and review health are part of the **Growth** plan and up. See [Plans](/plans).
</Note>