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.
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.
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.
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.
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.
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.
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.
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}}"}
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."
JQL queries find stuck tickets. They don't tell you why they're stuck or what to do. An autonomous status agent goes further:
The shift is from detection (JQL can do this) to diagnosis and escalation (which requires reasoning across multiple tools).
| Step | Tool | Output |
| Detect stuck tickets | Saved JQL filter | List of ticket keys |
| Categorise the cause | Atlassian Automation + Slack notification | Daily channel digest |
| Diagnose root cause | Manual investigation OR autonomous agent | Likely blocker per ticket |
| Escalate | Manager review OR auto-DM via agent | Concrete unblock action |
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.
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.
Don't run stuck-detection on epics — they always look stuck because they cover months. Filter to type != Epic in your JQL.
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