How to Add a Blocked Status in Jira

Here’s the thing most teams get wrong — they track what they’re working on, but not why it stopped.

A blocked status in Jira is a custom workflow status that signals a task or issue cannot move forward until an external dependency is resolved. It’s not just a label. When used properly, it becomes an early warning system that stops problems from compounding quietly in the background.

The data backs this up. According to a McKinsey study, knowledge workers spend 28% of their workday on unnecessary interruptions and follow-ups — much of which stems from unclear task dependencies. Teams that surface blockers visibly in their project tools reduce rework by up to 40%.

Jira doesn’t give you a “Blocked” status out of the box. But adding one is straightforward — if you know where to look.

Why Teams Add a Blocked Status in Jira

Before you touch a single setting, it’s worth understanding what problem you’re actually solving.

Most Jira boards operate with statuses like To Do → In Progress → Done. Clean, simple, and completely blind to what happens when a task hits a wall. When something is blocked, it either sits in “In Progress” (misleadingly), gets dragged back to “To Do” (losing context), or lives in comments nobody reads.

Research from the Project Management Institute found that poor project visibility costs organizations an average of $122 million for every $1 billion spent. Blocked work that isn’t flagged is invisible waste.

A dedicated blocked status fixes that by:

• Making dependency gridlock instantly visible on the board
• Giving team leads a real-time snapshot of what’s at risk
• Stopping the habit of burying blockers in Slack threads or comment sections
• Reducing the time spent in standups asking “wait, where is this actually at?”

If your team runs sprints, this matters even more. Studies show that 65% of sprint failures are directly tied to unresolved dependencies — not skill gaps, not poor planning, but blocked work nobody formally flagged.

How to Add a Blocked Status in Jira — Step by Step

Access Your Project Settings

Start in the Jira project where you want the blocked status. Click Project Settings in the left-hand sidebar. This is where all workflow configuration lives, and you’ll need project admin permissions to proceed.

If you don’t see the settings option, you’ll need to request admin access. In larger organizations, roughly 34% of Jira workflow requests are delayed simply because teams don’t have the right permissions from the start — so sort that out first.

Open the Workflow Editor

Inside Project Settings, navigate to Workflows. You’ll see a list of all active workflows in the project. Find the workflow tied to the issue type you want to modify (for example, Story, Task, or Bug) and click the pencil icon to edit it.

Jira will prompt you to create a draft of the workflow. Click Edit to confirm. This draft mode lets you make changes without affecting live issues until you’re ready to publish.

Add the Blocked Status

In the workflow editor, you’ll see a visual diagram showing your current statuses and transitions. To add a new status:

1. Click Add Status (top of the diagram or right-click the canvas area)
2. Type “Blocked” in the status name field
3. Choose a status category — select “In Progress” (since blocked items are technically active, just paused)
4. Click Add

The status category matters more than most people realize. Jira uses these categories (To Do, In Progress, Done) to calculate metrics like sprint velocity and cycle time. Assigning “Blocked” to the “In Progress” category keeps your burndown charts accurate.

Create the Transitions

A status without transitions is a dead end. You need to define how issues move into and out of the Blocked status.

To add a transition INTO Blocked:

1. Hover over the status you want to transition from (e.g., “In Progress”)
2. Click the Add Transition button that appears
3. Set the destination to your new “Blocked” status
4. Name the transition — “Mark as Blocked” works well
5. Click Add

To add a transition OUT of Blocked:

1. Hover over the “Blocked” status
2. Click Add Transition
3. Set the destination back to “In Progress” (or wherever makes sense for your flow)
4. Name it “Unblock” or “Resume Work”
5. Click Add

You can add multiple transitions out of Blocked if your team needs issues to skip directly to “In Review” or another status once resolved.

Publish the Workflow

Once your statuses and transitions look correct, click Publish in the top right. Jira will ask if you want to associate existing issues with the new workflow — select the appropriate scheme and confirm.

Publishing typically takes a few seconds. After that, the “Blocked” status will appear as an option on every issue in the project.

Apply the Workflow Scheme (If Using Company-Managed Projects)

For company-managed projects, you may need to update the Workflow Scheme to apply your changes to the right projects.

Navigate to Jira Settings → Issues → Workflow Schemes, find the scheme associated with your project, and ensure the updated workflow is mapped to the correct issue types. Then associate the scheme back to your project under Project Settings → Workflows.

This extra step trips up a lot of teams. According to Atlassian’s own community data, workflow scheme mismatches are among the top five most common Jira configuration errors reported by teams moving to company-managed setups.

Test It Before You Roll Out

Before announcing the new status to your team, run a quick test:

• Open any existing issue
• Check that “Mark as Blocked” appears in the status transition options
• Move the issue to Blocked
• Verify it shows correctly on the board
• Transition it back to In Progress using the “Unblock” option

Testing takes three minutes and saves an hour of confusion when your whole team is watching.

How to Make the Blocked Status Actually Useful

Adding the status is the easy part. The harder part is making sure your team uses it consistently. Here’s what separates teams that get real value from this setup versus those who forget the status exists after week two.

Make “why it’s blocked” mandatory. Use Jira’s transition screen configuration to require a comment or a linked issue whenever someone marks something as Blocked. Teams that document the reason at the point of blocking resolve dependencies 37% faster than those who don’t.

Add a Blocked swimlane or filter to your board. Create a board filter that surfaces all Blocked issues in one view. This makes your daily standup dramatically more efficient — instead of asking “what’s everyone working on,” you can ask “what’s still blocked and who owns the unblock?”

Set up a notification rule. Use Jira’s automation feature to send a notification to the project lead whenever an issue is moved to Blocked. Teams that implement automated blocker alerts reduce average resolution time from 4.8 days to 1.9 days, according to internal productivity benchmarks from Atlassian customers.

Review Blocked issues in every sprint retrospective. Track how many issues hit Blocked status each sprint, how long they stayed there, and what triggered them. Over time, this data tells you where your real process bottlenecks are — not just which individual tasks got stuck.

Common Mistakes When Adding a Blocked Status

Using the wrong status category. If you categorize Blocked under “To Do” instead of “In Progress,” your sprint metrics will look cleaner than they actually are. That’s a vanity fix, not a real one.

No transitions out. Some teams add the Blocked status but forget to configure the transitions back. Issues get stuck permanently in Blocked because there’s no path forward in the workflow — a painful irony.

Team-managed vs company-managed confusion. The workflow editor looks and behaves differently depending on your project type. Team-managed projects have simpler, more limited workflow controls. Company-managed projects give you full control but require more steps. If your changes aren’t appearing, this is usually why.

Not training the team. A new status is only as effective as the team’s understanding of when and how to use it. Take five minutes to explain the purpose in a team meeting. Adoption rates for new Jira statuses drop by roughly 60% when there’s no accompanying explanation — even simple ones.