PR cycle time: the dots the average hides
PR Cycle Time Scatter plots one dot per merged pull request — when it merged, how many hours it took open-to-merge, and a colour for its benchmark tier. Click any dot to drill into that author's PRs. It exists because a single median number can look fine while three PRs quietly wreck your week.
Cycle hours per merged PR, by merge date. Colour = benchmark tier.
What it measures, and where the data comes from
Every merged PR is one dot. X is the day it merged, Y is cycle hours — open to merge, wall-clock — and the colour is which benchmark tier that single PR landed in. Nothing is averaged away; a bad PR stays visible as a bad PR.
- GitHub — pull requests, opened-at to merged-at, per PR.
- GitLab — merge requests, same opened-to-merged window.
- Azure DevOps — pull requests, same window, from the repos you've opted into code intel for.
Click a dot and it drills into that author's PRs, filtered to them — useful for confirming whether a high dot is a one-off or a pattern for that person.
How to read it
Don't start with the average height of the cloud — start by scanning for dots that don't belong. A tight, low band with a couple of amber or red dots poking above it is a healthy team with a handful of PRs that need attention, not a team with a cycle-time problem.
Then look sideways. A cluster of slow dots all landing in the same week is a different story than scattered outliers — that's a calendar event (a crunch, a release, people out), not a chronic issue. Vertical position tells you severity; horizontal clustering tells you cause.
What it tells you over time
Watch whether the cloud is drifting upward as a whole, or whether it's staying low with occasional spikes. A rising cloud is a systemic slowdown — reviews, batch size, or process debt building underneath everyone. Occasional high dots in an otherwise low cloud are usually just big PRs, and big PRs happen; the question is whether the same author or same area produces them repeatedly.
This is also the widget that catches what a weekly average trend can't: a single 200-hour PR that got merged on a Friday doesn't move a median much, but it might represent three days of one engineer blocked, or a review that got rubber-stamped out of fatigue. The scatter keeps that PR visible instead of diluting it into "the week was fine."
Example situations
1. A couple of dots way above the pack
Two red outliers sitting far above an otherwise tight, low cloud.
What you're seeing: nine dots hugging a tight, low band, and two sitting way above everything else. If you only watched a weekly average, these two would barely nudge it — the median absorbs them.
Which PR is it? Hover a dot and the tooltip names it — repo #1204 with the pull request's title underneath, plus its author and cycle time. Before that, the tooltip showed only the two axis values, so an outlier was visible and unidentifiable at the same time.
How to react: click the highest one first. Nine times out of ten it's a genuinely large change — a migration, a refactor, a rewrite — that should probably have been split, or a PR that sat waiting on an external dependency (design sign-off, a blocked environment, a third-party review). Either way, find out before you assume it's a person problem.
2. A vertical wall of slow dots in one week
A cluster of medium/low dots all merging the same week — everything else stayed fast.
What you're seeing: a wall of amber and red dots sharing roughly the same x-position, with fast, low dots on either side of it. This isn't one bad engineer or one bad PR — it's one bad week for everybody who happened to merge during it.
How to react: line the week up against your calendar before you look anywhere else. It's almost always a release freeze that backed everything up, a reviewer or two out at the same time, or a crunch where everyone was heads-down and nobody had review bandwidth left over.
Frequently asked
- What does the PR cycle time scatter show?
- One dot per merged pull request: when it merged, how many hours it took from open to merge, and a colour for its benchmark tier. Clicking a dot drills into that author's pull requests.
- Why use a scatter instead of an average?
- Because a median can look healthy while a handful of pull requests quietly wreck a week. The scatter makes those outliers visible, which an average is specifically designed to hide.
- How do I spot a crunch week?
- Look for a vertical cluster of dots at unusually high cycle hours on one date range. That shape usually means a batch of work was held and merged together rather than that everything slowed down evenly.
Related widgets
- Lead Time for Changes — the weekly median this scatter's dots roll up into.
- Review Pickup Time — isolates the reviewer-wait slice that often explains a high dot.
- DORA Metrics — the four-key scorecard that lead time (and by extension this widget) feeds into.
- Back to the widget reference.
Last updated