Jira

How to detect blocked Jira tickets automatically

Most "blocked" tickets aren't tagged Blocked — they're stuck silently. Here are five JQL queries, two automation rules, and one autonomous escalation pattern to catch them before sprint review.

7 min read · Updated 2026

Why explicit "Blocked" status isn't enough

The word "blocker" implies someone declared it. In practice, the most dangerous tickets are the ones that nobody flagged — they're In Progress for 8 days, the assignee got pulled to a fire, and they sit silently. By the time anyone notices, the sprint is over.

Detecting these requires looking at activity, not status. A ticket that hasn't moved in 5 days is functionally blocked, regardless of label.

Five JQL queries you should save

1. Stuck more than 3 days, not Done

updated <= -3d AND statusCategory != Done AND sprint in openSprints()

The bread and butter. Run this every Monday morning. Anything that surfaces here either needs unblocking or needs to be moved out of the sprint.

2. In Progress for 7+ days

status = "In Progress" AND statusChangedAfter() <= -7d

A ticket can sit in In Progress legitimately for a week if it's a 13-pointer. But if it's a 3-pointer, that's a signal something's wrong.

3. Assigned but unaddressed

assignee is not EMPTY AND status = "To Do" AND created <= -5d AND sprint in openSprints()

Tickets assigned to someone who never started them. Often a sign of capacity overload or a hidden dependency.

4. High priority + recent inactivity

priority in (Critical, High) AND updated <= -2d AND statusCategory != Done

Critical work going silent is the single most dangerous signal in any sprint. Run this daily, not weekly.

5. Bouncing between statuses

status changed FROM "In Progress" TO "To Do" AFTER -14d

Tickets that move backward usually mean an estimation problem or a hidden dependency. Catching these reveals systemic issues, not just individual ones.

Automation rules to layer on top

Slack notification on stuck tickets

Atlassian Automation rule: trigger every weekday at 09:00, run JQL query #1, post matching tickets to a Slack channel via outgoing webhook.

Trigger: Scheduled (cron 0 9 * * 1-5)
Branch: For each issue matching JQL ("stuck more than 3 days")
  Action: Send web request to https://hooks.slack.com/...
  Body: {"text": "🛑 {{issue.key}} stuck {{issue.updated}} days — assignee: {{issue.assignee.displayName}}"}

Auto-comment when high-priority goes quiet

Trigger: Issue updated, then 48h timer
Condition: priority is Critical OR High; status not Done
Action: Add comment "@{{issue.assignee.displayName}} — this ticket has been quiet for 48h. Flag a blocker if you have one."
Trap to avoid: Automation rules that just notify, without context, become noise within two weeks. The notifications must include the ticket key, the days stuck, and ideally the suggested next action — otherwise they're cargo-cult automation.

Beyond JQL: what an autonomous agent does differently

JQL queries find stuck tickets. They don't tell you why they're stuck or what to do. An autonomous status agent goes further:

  1. Runs the JQL queries above (or equivalent API calls).
  2. For each stuck ticket, reads the linked PRs to see if there's an unmerged review.
  3. DMs the assignee with a specific question: "TICKET-X has been stuck 5 days, PR #42 has 2 unresolved review comments — is that the blocker?"
  4. Aggregates responses across the team and surfaces patterns ("3 tickets blocked by reviews from same person") in the weekly report.
  5. Recommends owner-attributed actions: "Senior reviewer rotation needed — current bottleneck is one person."

The shift is from detection (JQL can do this) to diagnosis and escalation (which requires reasoning across multiple tools).

The detection-to-action pipeline

StepToolOutput
Detect stuck ticketsSaved JQL filterList of ticket keys
Categorise the causeAtlassian Automation + Slack notificationDaily channel digest
Diagnose root causeManual investigation OR autonomous agentLikely blocker per ticket
EscalateManager review OR auto-DM via agentConcrete unblock action

FAQ

What's the right "stuck" threshold?

3 days for a 1-week sprint, 5 days for a 2-week sprint. If you set it to 1 day you'll get noise; if you set it longer than half the sprint length, you'll find out too late.

How do I handle false positives?

Long-running tickets like spikes or research often look "stuck". Add a label like research or spike and exclude it from your stuck-ticket query.

What about epics and parents?

Don't run stuck-detection on epics — they always look stuck because they cover months. Filter to type != Epic in your JQL.

Want this fully automated?

Recapline runs all five queries, reads PR data, asks each blocked engineer one specific question, and writes the escalation report. Free up to 10 users.

Install on Jira Cloud →

Related: Weekly status report template · AI stand-up bots vs traditional