This guide brings together common pull request (PR) flow issues in LinearB and how to fix them: slow pickup and review times, large PRs that block progress, PRs that don’t appear in reports, unlinked branches, and reviews that never start.
TL;DR – What you can do from here
- Pickup time is high: Use alerts, WorkerB, and metrics dashboards to make sure PRs are seen and owned quickly.
- Review time is high: Surface hanging reviews, rebalance WIP, and break down large PRs.
- Large PRs cause friction: Use PR Size metrics, ETR labels, and alerts to drive smaller, more frequent changes.
- PRs not showing: Check integrations, teams, filters, and unlinked branches.
- Review request hanging: Use “Review Request Hanging” filters and alerts to catch PRs waiting for a first review.
Reducing Pull Request Pickup Time
Pickup Time measures how long a PR waits from creation (or “ready for review”) until the first review starts. High pickup time slows down delivery and leads to stale work.
What “high” pickup time usually means
- Elite teams aim for pickup under 24 hours, and PRs should not wait more than 48 hours for first review.
- If the Pickup metric is red on the Home dashboard, your team’s average pickup time is too high.
How to identify where pickup is slow
- Across teams: On the Home dashboard, set the view to All Teams and click the Cycle Time → Pickup metric to see which teams are struggling.
- By person: In People → Team → Activity, select the team and look at the Cycle Time values per person to see whose PRs tend to wait longest.
- By PR: In Metrics → Pull Requests, apply the Review Request Hanging filter to find PRs waiting for review (for more than 3 days or using a custom date range).
Typical causes of high pickup time
- Lack of awareness – PRs are opened but no one knows they exist.
- Team overload – too much WIP; reviewers don’t have capacity.
- PRs are too large – people avoid opening a “big, scary” review.
- Unclear ownership – no one feels responsible for picking up the PR.
How to reduce pickup time
1. Set up Slack alerts for hanging PRs
Configure team-level alerts so Slack channels are notified when PRs have been waiting too long:
- In LinearB, Select a Team from the top right team selection drop down
- Open the team Settings.
- Go to the Goals tab.
- Edit the Pull Request Pickup Time goal.
- Set an alert threshold you’re comfortable with.
- Save the goal and ensure Slack alerts are enabled for the team.
Note: Also enable the Pull Requests Merged without Review alert so you don’t end up merging PRs that never got picked up.
2. Enable WorkerB personal Slack alerts
WorkerB sends direct messages when PRs are assigned, updated, or need action:
-
/lb invite– invite team members to connect WorkerB. -
/lb pref– manage personal notification preferences. -
/lb reviews– see PRs assigned to you. -
/lb prs– see PRs you created. -
/lb updates– see recent PR activity relevant to you.
Personal alerts ensure that when someone is the owner of a review, they actually see it.
3. Use metrics dashboards to track pickup
In the Metrics tab, you can build a dashboard that includes:
- Pickup Time – to track trends and see if improvements stick.
- PR Size – to correlate large PRs with slow pickup.
- Active Branches – to understand WIP and reviewer load.
4. Monitor large PRs and WIP
Use Pulse, Team Activity, and PR Size metrics to keep an eye on:
- Developers who consistently create large PRs.
- Teams with too many active branches per person.
Reducing PR size and balancing work in progress will naturally reduce pickup time.
Reducing High Pull Request Review Time
Review Time measures how long a PR stays in review after the first reviewer starts. Even if pickup is fast, long reviews can stall delivery.
When review time is considered high
- Industry benchmarks suggest PR reviews should complete in under 2 days.
- If the Review metric is red on the Home dashboard, your team’s review time is above your target.
How to find long reviews
- Metrics →Git Activity → Pull Requests: In Git Activity, switch to Pull Requests, open Additional Filters, set PR State → In Review, then sort by Updated to find the oldest reviews.
Common causes of high review time
- Team is unaware / distracted – reviewers are not actively watching the queue.
- Team is too busy – heavy WIP or firefighting reduces review capacity.
- PRs are too large – big changes take longer and are easier to postpone.
How to reduce review time
1. Use WorkerB in Slack/MS Teams alerts for long reviews
Use team alerts for Review Request Hanging and long-running reviews so the team is notified when PRs sit in review beyond your threshold.
2. Enable WorkerB personal alerts for reviewers
WorkerB personal alerts help reviewers stay on top of:
- PRs assigned to them.
- New comments requiring follow-up.
- Updates on PRs they’re reviewing.
This prevents reviews from stalling simply because someone missed a notification.
3. Manage large PRs
Large PRs are one of the biggest drivers of long review time. See Managing Large Pull Requests below for concrete patterns and actions.
4. Make review checks a habit
- Regularly scan the Review Request Hanging view.
- Use weekly/iteration reviews to look at Review Time metrics and discuss blockages.
Managing Large Pull Requests
Large PRs increase pickup time, review time, and the chance of defects. LinearB gives you several ways to identify and manage large PRs so you can encourage smaller, more frequent changes.
Where to see PR size
- In Metrics → Pull Requests, use PR Size and related filters to find PRs with many lines changed.
- In Pulse, you can see PRs with high estimated time to review (ETR).
Patterns to look for
- PRs with a very high line count (for example, changes in the hundreds or thousands).
- PRs bundling multiple logical changes (features, refactors, config, tests) into one review.
- PRs that frequently trigger long review or multiple rework cycles.
How LinearB helps you manage large PRs
1. Use gitStream estimated time to review (ETR)
ETR labels on PRs help reviewers understand the expected effort at a glance. This can be used to prioritize small PRs and call out large ones that need extra attention.
2. Use WorkerB alerts to highlight large PRs
Configure goals and alerts around PR Size and Review Time so Slack channels are notified when a large PR has been waiting too long or has been in review for too long.
3. Use gitStream to automate reviewer assignment and context
With gitStream, you can:
- Assign expert reviewers automatically for large or complex changes.
- Add labels or comments highlighting that a PR is large and may require more reviewers.
- Apply different rules for large PRs versus small PRs.
4. Encourage smaller, more focused PRs
Use the data you see in Metrics and Pulse to set expectations:
- Share examples of PR size ranges that review quickly and safely.
- Encourage splitting work into multiple PRs when changes grow too large.
Review Request Hanging
Review Request Hanging highlights PRs where review has been requested but no reviewer has started the review within a reasonable time (for example, more than 3 days).
What it means
- A PR was created and marked “ready for review”.
- Reviewers were requested.
- No reviewer has started a review (no comments or approval) within the configured window.
How to use it
- In Metrics → Pull Requests, apply the Review Request Hanging filter to see PRs stuck waiting for a first review.
- Turn on Review Request Hanging Slack alerts so team channels are pinged when PRs cross your threshold.
- Use this data in retros to talk about review ownership and expectations.
Addressing Review Request Hanging is often the fastest way to improve both Pickup Time and Review Time, because it surfaces PRs that no one has really “taken responsibility” for yet.
Troubleshooting
Pull Requests Not Showing in LinearB
Sometimes a PR exists in your git provider but doesn’t appear in LinearB metrics or views. This section walks through the most common reasons and how to fix them.
Unlinked Branches
Unlinked branches are branches where LinearB sees commit activity but cannot connect the work to any PR. This can affect metrics like Cycle Time and Deployment Frequency because the branch never “lands” in a PR that LinearB can track end-to-end.
Why branches may be unlinked
- PRs are created in a different repo than where the branch lives.
- Branches are merged via fast-forward or command line without an associated PR.
- Branch and PR naming conventions don’t match your organization’s patterns.
- Branches are deleted before LinearB can detect a matching PR.
How to work with unlinked branches
- Standardize how PRs are opened (always from branches tracked by LinearB, always against the same repos).
- Encourage PR-based merging instead of direct merges where possible.
- Use consistent naming conventions so branches and PRs are easier to match.
If you see a lot of unlinked branches for a team, share specific examples with your LinearB team so they can confirm whether configuration changes would help.