Blockers are inevitable. What separates high-performing teams is how they surface, communicate, and resolve them. Here's the workflow we use at Sunday.
A blocker is a specific workflow state where work has stopped and cannot resume until an external dependency is resolved. Unlike a task marked "not started" or "low priority," a blocker has a known cause, a known owner, and a known ETA — work isn't stuck arbitrarily, it's waiting on something specific.
Most project tracking software treats blockers as a checkbox or a status flag. The teams that handle blockers well treat them as a structured workflow state — with type, ETA, required action, and visual indicators that make the blocker impossible to ignore.
A well-tracked blocker has four components:
1. Type — Internal or External. Internal blockers are waiting on someone inside your organization (a team member, another department). External blockers are waiting on something outside (a vendor, a client, a partner, a regulatory body).
2. ETA — When do you expect the blocker to be resolved? This isn't a promise, it's an estimate. But having a date forces the conversation: "I thought this would be done Friday, it's Wednesday, we need to talk."
3. Required action — What needs to happen for this blocker to resolve? "Waiting on design assets," "Waiting on client approval," "Waiting on server access from IT." Specific, actionable, visible.
4. Visual indicator — The ticket should show immediately that it's blocked. Not buried in a status field. Not hidden in a filter. Visually prominent.
This is what separates real blocker tracking from just adding a "blocked" checkbox.
The danger with blockers isn't the delay itself — it's the silence. When a ticket gets blocked and nobody talks about it, three things happen:
1. Other work gets misprioritized. Teammates don't know this ticket is blocked, so they don't know to deprioritize related work or check on dependencies.
2. Standups become useless. "What are you working on?" — "Still on the API ticket." — "Any blockers?" — "Not really." Meanwhile the ticket has been blocked for a week because legal hasn't signed off on the vendor contract.
3. Deadlines slip silently. Without visible blocker tracking, you don't know a deadline is at risk until it's too late. The PM assumes work is proceeding. The engineer assumes someone else is handling the external dependency. Nobody's talking.
The fix isn't more meetings. It's better visibility.
Here's how we handle blockers at Sunday — and how teams using our ticket management software replicate it:
Step 1: Mark the ticket as blocked immediately. When work stops, the ticket status moves to Blocked. Not Working. Not Backlog. Blocked. The visual indicator updates immediately.
Step 2: Classify the blocker. Is it internal or external? This affects who gets notified and how. Internal blockers usually resolve faster and need team-level visibility. External blockers need stakeholder management and realistic ETA tracking.
Step 3: Set the required action and ETA. "Waiting on legal to review vendor contract — ETA Friday." This forces accountability. Someone owns the unblocking. There's a date.
Step 4: Update weekly. If the ETA passes and the blocker isn't resolved, that's a conversation. Not a blame — a real conversation about what changed, what the new ETA is, and whether leadership needs to be involved.
Step 5: Resolve and document. When the blocker resolves, the ticket moves back to Working. The blocker history is preserved — useful for understanding patterns ("why do we always get blocked on vendor contracts?").
A team at a fintech company was migrating their infrastructure to a new cloud provider. Fourteen tickets in the migration project. Six of them were blocked at some point — vendor access delays, compliance review cycles, internal IT bottlenecks.
Without blocker tracking, the PM only found out about blocks during standups — sometimes days late. Delivery estimates were constantly wrong.
With blocker tracking:
The migration finished three days ahead of schedule — not because blockers didn't happen, but because blockers were surfaced fast enough to adapt.
Mistake 1: Marking tickets as "in progress" when they're blocked. If a ticket is blocked, the status should be Blocked — not Working. Misleading status is worse than no status.
Mistake 2: Not classifying internal vs external. "Blocked" doesn't tell you much. "Blocked — external vendor, ETA Wednesday" tells you everything. The classification changes how you manage the blocker.
Mistake 3: Setting ETAs you can't enforce. An ETA on an external blocker is a commitment from the external party, not yours. If the vendor says Friday but hasn't confirmed, don't put Friday. Put "TBD — following up Monday" and actually follow up.
Mistake 4: Forgetting to update. Blockers don't resolve themselves. If the ETA passes and nothing changed, someone needs to have the conversation. The system reminds you; humans still need to act.
The technical part is easy — it's the cultural part that matters. In teams that handle blockers well, blocking a ticket isn't a failure. It's a signal. When something gets blocked, the response isn't "why did you let this happen?" It's "what do you need to unblock it?"
That shift — from blame to action — is what makes blocker tracking work. The tool surfaces the problem. The culture determines whether people feel safe reporting it.
Sunday's ticket management software includes dedicated blocker tracking with internal/external classification, ETA fields, required action notes, and visual indicators that make blocked tickets impossible to miss.
Want to see how blocker tracking works in practice? <a href="/dashboard" className="text-[#D6BFA3] hover:underline">Try Sunday's dashboard</a> — block your first ticket and see how it looks.
Try Sunday's ticket management platform — start free, upgrade when you're ready.
Start for free