This guide explains how LinearB surfaces risky or unusual pull requests and branches, and what to do when you see them. These views are designed to help you catch problems early: unreviewed merges, high rework, risky work, high interaction PRs, lightning PRs, long living PRs, and branch outliers.
TL;DR – Where to focus
- Workload & Burn out Indicators: Learn which developers are "always on"
- PRs Merged w/o Review: tighten review policies and alerts.
- High interaction PRs: look for design disagreements or unclear requirements.
- High rework: investigate code churn and unstable areas of the codebase.
- Risky work: large changes mostly touching existing code – plan extra testing.
- Lightning PRs: very fast reviews that may h ave been superficial.
- Long living PRs: old, unmerged PRs that stall progress.
- Branch outliers: branches that behave very differently than the norm and need attention.
Workload & burnout indicators
LinearB includes a set of burnout indicators that look at how much work a developer is carrying over time, based on Git Activity.
Burnout
A developer is flagged with a Burnout indicator when they have work in progress on 90% or more of the days in the selected period (for example, a sprint).
This can signal they are always on and not getting breaks between tasks, which may lead to burnout.
Cognitive overload
Cognitive overload is triggered when a developer has more than 6 active branches at the same time.
Juggling many active tasks increases context switching and makes it harder to finish work efficiently.
Underloaded
Underloaded is shown when a developer has 0 active tasks over the measured period.
This can indicate someone is not being utilized, or that work is unevenly distributed across the team.
Note: These indicators do not replace 1:1 conversations, but they provide an early signal when workload patterns may be unhealthy for an individual or for the team.
Pull Requests Merged Without Proper Review
LinearB flags PRs that were merged with little or no review so you can prevent risky changes from reaching production unnoticed.
Common patterns
- PRs merged with no review at all.
- PRs merged after only the author reviewed their own code.
- PRs merged with a very low number of review comments compared to the size of the change.
Why it matters
- Increases the chance of bugs and regressions.
- Undermines the team’s review culture.
- Makes it harder to enforce compliance and quality standards.
What you can do
- Turn on PRs Merged without Review alerts so teams see when this happens and can inspect the specific PR.
- Use branch protection rules in your git provider to require at least one or two approvers before merging.
- Encourage teams to treat this view as a weekly “safety scan” and discuss any exceptions together.
High Interaction Pull Requests
High interaction PRs are pull requests with a large number of review comments. They can signal deep collaboration—or friction and confusion.
What LinearB highlights
- PRs with a high number of comments in the review thread (for example, 10+ comments).
- PRs where discussion spans multiple reviewers and many back-and-forth cycles.
Why it matters
- May indicate low initial code quality or unclear requirements.
- Can reveal architectural disagreements between senior engineers.
- Often correlates with high rework and longer cycle time.
How to use it
- Open the PR and skim the discussion to understand the root cause (design, requirements, style, testing, etc.).
- Use examples in retrospectives to improve upfront design and specification.
- Support reviewers and authors if you see recurring misunderstandings between the same people or teams.
High Rework
High Rework highlights branches where a large portion of changes are re-editing recently added code, leading to code churn and instability.
How LinearB defines high rework
- A high percentage of rework (for example, > 30% of the changes revisiting recently added code).
- A large total number of changed lines (for example, > 300 lines of code modified).
- Branches that are still active (recently updated).
Why it matters
- Suggests unstable requirements or design.
- Can signal quality issues, especially when rework happens soon after the original changes.
- Indicates wasted effort and potential developer frustration.
How to respond
- Look at what is being reworked – the same files, modules, or services over and over.
- Discuss whether these areas need clearer ownership, better tests, or refactoring.
- Use examples in design reviews to improve how similar changes are approached next time.
Risky Work
Risky work flags branches where a large number of changes are applied mostly to existing code, with relatively little new code being added.
Typical pattern
- Large change volume – many lines modified.
- Most changes affect existing code – a small fraction of changes are new code.
Why it matters
- Changing existing, production-critical code carries higher risk than adding new code in isolation.
- Refactors and behavior changes can introduce subtle regressions.
- Often requires deeper reviews and more robust testing.
What to do when you see risky work
- Ensure senior or domain-expert reviewers are assigned to the PR.
- Plan for extra testing and, if appropriate, feature flags or gradual rollout.
- Use this view to prioritize which branches deserve extra attention in a given iteration.
Handling high-risk work
High-risk work in LinearB highlights branches with large change volume where most of the changes are rework or refactor. These branches are more likely to introduce defects and should be treated carefully.
- Use the High-Risk Work filter in Activity to find branches with many code changes and a high share of rework/refactor.
- Assign multiple reviewers, ideally including someone who knows the affected code well.
- Increase tests for these branches: add or strengthen unit tests and integration tests around touched areas.
- Where possible, break very large changes into smaller PRs so they’re easier to review, reason about, and roll back if needed.
Lightning Pull Requests
Lightning PRs are PRs that move from “in review” to “merged” very quickly after review starts (for example, reviews completed within 0–20 minutes).
Why this can be risky
- Some changes truly are trivial, but many “lightning” reviews are superficial.
- Complex or large PRs that get lightning-fast approval may not have been examined carefully.
How to use lightning PRs
- Check whether the PR size and complexity match the review time.
- Use this as a coaching tool: encourage reviewers to invest enough time for non-trivial changes.
- Combine with PR Size and Merged without review views to get a balanced picture.
Long Living Pull Requests
Long living PRs are pull requests that were opened a long time ago and are still not merged. For example, PRs that:
- Were created more than about 30 days ago, and
- Are still in Initiated or In Review state.
Why long living PRs are a problem
- They block code from shipping and clutter the review queue.
- They often represent work that has lost priority or ownership.
- When they do get merged, they can be large, hard to review, and risky.
What to do with long living PRs
- Decide whether each PR should be:
- Merged soon (with dedicated review time), or
- Closed and replaced with a new, smaller PR if needed.
- Use this list in grooming sessions to clean up stale work.
- Look for patterns (e.g., certain services, teams, or authors) and address root causes.
Branch Outliers
LinearB also classifies branches as outliers when their behavior is very different from your typical branches for the same team and time period.
What makes a branch an outlier
- Unusually long cycle time compared to similar branches.
- Exceptionally large number of lines changed.
- Very high rework or many rework iterations.
The exact thresholds are calculated based on your team’s recent branch history, not a fixed global number. Branches that significantly exceed those baselines are surfaced as outliers.
How to use branch outliers
- Inspect outlier branches to learn where your process breaks down (requirements, design, dependencies, etc.).
- Look for repeated patterns:
- Specific services or repositories that always show outliers.
- Types of work (new features vs. refactors) that tend to go off the rails.
- Bring a small list of outliers into planning or retro to discuss what you’d do differently next time.
Using These Signals Together
Each risk or outlier filter is useful on its own, but they are most powerful when combined:
- High interaction + high rework + risky work often points to unstable designs or unclear requirements.
- Lightning PRs + merged without review can reveal gaps in review discipline.
- Long living PRs + branch outliers highlight work that is stuck and risky at the same time.
Use these views weekly with your team to:
- Spot risky work before it ships.
- Align on review expectations and ownership.
- Continuously improve how you plan, implement, and review changes.