What is a Blocker?
Blocker
A blocker is a specific obstacle that stops one task from moving forward, usually because it depends on someone or something outside the assignee's control.
A blocker is a specific obstacle that stops one task from moving forward. It's narrower than it sounds: not a general slowdown across the team, and not a person avoiding work. A blocker means one task, on one card, is waiting on something outside the assignee's control, a client asset that hasn't arrived, a signature nobody has given, an API key another team owns.
That narrowness is what makes it worth naming separately from other things that stall work. A bottleneck is a structural constraint that limits an entire workflow's throughput, the kind of problem that reappears with every new task passing through it. Procrastination is a person delaying a task they're fully capable of starting. A blocker is neither: the task can't move because it's genuinely stuck on an external dependency, and clearing that one dependency unsticks it completely.
On a Kanban board, a blocker looks identical to a stalled task until someone flags it. A card sits in "In Progress" with no time logged for three days. Without a note explaining why, a manager has to guess whether the assignee is behind, distracted, or stuck. Logging the blocker the moment it appears turns an invisible delay into a visible, assignable problem.
What Counts as a Blocker
Not every delay is a blocker. A task is blocked when the next action belongs to someone other than the assignee, and no amount of effort from the assignee moves it forward without that input.
- Waiting on a client asset: logo files, copy, product photos, an API credential the client controls
- Waiting on approval: a design, a draft, or a budget increase sitting with a decision-maker
- Waiting on another team: a task that can't start until a dependency finishes elsewhere
- Waiting on a vendor or third party: a domain transfer, a plugin license, a hosting migration
- Waiting on a decision: the task can proceed multiple ways and nobody has picked one
Blocker vs Bottleneck vs Procrastination
These three get confused because they all show up the same way on a board, a task that isn't moving. The difference is scope, and who's responsible for resolving it.
| Blocker | Bottleneck | Procrastination | |
|---|---|---|---|
| Scope | One task, one dependency | A whole stage of the workflow | One person's relationship to one task |
| Cause | Something external hasn't arrived yet | Structural: a capacity or process limit | No clear first step, or no near-term cost to waiting |
| Who resolves it | Whoever holds the missing input | The team, through capacity or process change | The assignee, once the task is redesigned or checkpointed |
| Typical fix | Chase the specific input | Add capacity, redistribute work, redesign the process | Shrink the task or add an interim deadline |
How to Log a Blocker So It Gets Seen
A blocker that lives only in someone's head doesn't help anyone. Logging it the same day it appears turns "I'm stuck" into a specific, assignable problem with an owner and a follow-up date attached.
- Flag the card status as Blocked, not left sitting in In Progress
- Name exactly what's missing, not "waiting on client" but "waiting on final logo files from Client X"
- Name who owns the missing input: a specific person, not a department
- Set a follow-up date: when you'll chase it if nothing arrives
- Note the date the block started, so blocked time is visible separately from work time
When to Chase and When to Wait
Chasing too early looks pushy. Waiting too long lets a two-day delay become a two-week one. The right interval depends on who holds the blocker.
| Blocker source | First follow-up | Escalate to a manager or account lead |
|---|---|---|
| Internal team (another department) | 1 business day | After 3 business days with no response |
| Client (asset, approval, decision) | 2 business days | After 5 business days with no response |
| Vendor or third party | Per their SLA, or 3 business days if none stated | After the SLA window passes with no update |
A Worked Example: A Blocked Task at a 9-Person Studio
A 9-person design studio is mid-way through a rebrand for a retail client. The task "Finalize brand color palette" is marked In Progress on Monday, waiting on the client's confirmation of which of three directions to move forward with.
No one logs the block. By Thursday, the designer has quietly moved on to other work, and the palette task still shows In Progress with zero time logged since Monday. The project manager assumes it's nearly done, because nothing on the board says otherwise. On Friday, during a client call, the studio learns the client sent their decision by email on Tuesday, three days earlier, to an account manager who was out of office.
Three days were lost not because the client was slow, but because nobody logged the block or set a follow-up. If the card had been marked Blocked on Monday with a note ("waiting on palette decision from Client X, follow up Wednesday if no reply"), the follow-up would have happened Wednesday, the email would have surfaced a day later, and the studio would have kept two of the three lost days.
- Cost of the unlogged block: 3 days lost on a task originally scoped for 1
- Cost of a logged block with a Wednesday follow-up: roughly 1 day lost instead of 3
Blockers in Melororium
Every task card in Melororium's Tasks module carries a status and a comment thread, so a blocked task can be flagged in place instead of quietly sitting in a normal column. Project Alerts watches for cards that haven't changed status in a set number of days (the Bottleneck alert, default 5 days) and surfaces them in Inbox, Slack, or email, catching both a structural bottleneck and a single unlogged blocker the same way, since both look identical to the system: a card that stopped moving.
Because the alert fires on inactivity rather than a manual status field, a blocker gets caught even if nobody remembers to mark the card. Project Alerts is included from the Agency plan up, $59/mo for 15 users, and isn't part of Starter.
In Melororium
Catch blocked tasks automatically in Melororium
Common mistakes with blocker
What teams get wrong most often, and what to do instead.
- 1
Marking blocked but not saying what's missing
Flipping the status to Blocked without naming what's needed or who owns it. A card that only says "blocked" still requires someone to track down the actual holdup.
- 2
Waiting too long to escalate a client-side block
Letting a blocker sit for a week out of politeness. A blocker with no follow-up date doesn't get chased, it gets forgotten until the deadline is already at risk.
- 3
Treating every blocker as a bottleneck
Redesigning a whole workflow because one task got stuck once. A single blocked task usually needs a phone call, not a process overhaul.
- 4
Absorbing the delay without telling the client
Quietly working around a missing client asset instead of flagging that the delay sits on their side. The deadline slips and the client assumes it's the agency's fault.
Frequently asked questions
Is a blocker the same as a dependency?
Related but not identical. A dependency is planned: task B is scheduled to start after task A finishes, and that's expected from the start. A blocker is unplanned: a task that should be moving is stuck because something it needs hasn't shown up on schedule.
Who should own clearing a blocker?
Whoever is closest to the missing input, usually the task assignee for internal blockers and the account lead for client-side ones. The task stays assigned to its original owner; only the chase-down responsibility shifts.
How long can a task sit blocked before it's a problem?
There's no universal number, but 2 to 3 business days without a follow-up attempt is a reasonable point to check in, sooner if the task sits on a hard deadline.
Does marking a task Blocked pause its deadline?
Not automatically in most tools, including Melororium. Marking a card Blocked flags the reason it isn't moving; the due date still has to be adjusted manually once the delay's length is known.
Can a task be blocked by more than one thing at once?
Yes, though it's worth logging each one separately. A task waiting on both a client asset and an internal approval has two different people to chase, and combining them into one vague note makes it harder to tell which one cleared first.
