You're halfway through your sprint. Three tickets have been "In Progress" for four days. Nobody mentioned it in standup. The sprint ends and two of them carry over. Sound familiar?
Blockers are the silent killer of sprint velocity. And they're almost always visible in your data, if you know where to look.
What a blocker actually looks like in Linear
A blocker isn't always labeled as one. It can look like:
- A ticket that's been "In Progress" for 3+ days without a comment or status change
- A ticket assigned to someone who's been out sick or in back-to-back meetings
- A ticket waiting on a code review that nobody has started
- A ticket blocked by an external dependency that wasn't flagged upfront
Linear has a "blocked" status and the ability to mark issues as blocked by other issues. But most teams don't use these features consistently. And even when they do, you still have to manually check.
How to find blockers in Linear today
Here's the manual process:
Step 1: Open your active cycle. Sort issues by status.
Step 2: Look for anything in "In Progress" that hasn't been touched recently. Click into each one and check the last comment or activity date.
Step 3: Check your "blocked" filter. Go to Issues, filter by "Blocked" status. These are the issues someone explicitly flagged.
Step 4: Cross-reference with your standup notes. Did someone mention a dependency last week that never got resolved?
This takes 15 to 20 minutes per sprint if you do it manually. Most engineering managers do it once a week at best, which means blockers sit for 3 to 4 days before anyone notices.
The cost of a late-detected blocker
A ticket stuck for 3 days in a 10-day sprint is 30% of your sprint capacity for that person, wasted.
If one engineer is blocked for 3 days and you have a 2-week sprint, that's half a week of productivity gone. Multiply that across 2 or 3 people and you understand why sprint goals get missed.
The problem isn't the blocker itself. It's the detection lag. If you catch a blocker on day 1, you can reassign work, unblock the dependency, or adjust the sprint scope. If you catch it on day 5, you're already behind.
What good blocker detection looks like
Automated blocker detection should surface:
- Any ticket In Progress with no activity for more than 48 hours
- Any ticket explicitly marked as blocked with the blocking issue still open
- Any ticket assigned to a team member with zero movement this sprint
- Any ticket in the cycle with a due date that's at risk based on current pace
You want this to be automatic. You don't want to run a manual query every morning before standup.
Building your own blocker alert system
If you want to DIY this, you can use Linear's webhooks to build a simple Slack notification system.
The setup looks like this:
- Create a webhook in Linear that fires when an issue status changes to "Blocked"
- Set up a cron job that queries Linear's API daily, looking for issues In Progress with no recent updates
- Post a Slack message each morning with the list of at-risk tickets
This works. It takes a day or two to build and set up, plus ongoing maintenance when Linear changes their API.
SprintIQ: automatic blocker detection for Linear
SprintIQ does this automatically, with no setup required.
Connect your Linear workspace via OAuth (30 seconds, read-only access) and SprintIQ will:
- Surface any ticket that has been In Progress for more than 48 hours without an update
- Show you blocked tickets across all your active cycles in a single view
- Flag at-risk issues before your daily standup, not after your sprint retrospective
You open SprintIQ before standup, see the blockers, and bring them up with the team. That's it.
Free to start. No credit card required.