How Do You Find Issues That Keep Returning to the Same Status in Jira?

[#1]

Most Jira teams track things like:

• Issues currently in QA

• Issues waiting for review

• Issues breaching SLAs

• Issues stuck for too long

But there's another category of issues that often flies under the radar.

The issues that keep coming back.

For example:

In Progress → Code Review → In Progress → Code Review → In Progress

Or:

QA → Reopened → QA → Reopened → QA

These issues aren't necessarily blocked.

They aren't necessarily overdue.

In many cases, they look perfectly healthy on dashboards because they're constantly moving.

Yet they're often the issues consuming the most engineering effort, review cycles, testing time, and team attention.

While working on StatusClock, we spoke with Jira administrators and engineering teams who wanted answers to questions like:

• Which issues keep failing QA?

• Which stories repeatedly return from Code Review?

• Which tickets are creating the most rework?

• Which workflow stages generate the most bounce-backs?

• Which issues might be impacting automation assumptions?

Surprisingly, these questions are difficult to answer using native JQL.

That's why we introduced:

StatusBounces()

issue in StatusBounces("statusName", "operator", count)

The function searches issue history and returns issues that have entered the same status multiple times.

Find issues repeatedly returning to development

issue in StatusBounces("In Progress", ">", 3)

Find issues that keep failing QA

issue in StatusBounces("QA", ">", 2)

Find stories repeatedly cycling through code review

issue in StatusBounces("Code Review", ">", 2)

Why does this matter?

Many teams measure:

• Cycle Time

• Lead Time

• Time in Status

• Throughput

But these metrics don't always reveal how much rework occurred before completion.

Consider two completed stories.

Story A:

Open → In Progress → Done

Story B:

Open → In Progress → Review → In Progress → Review → QA → Reopened → QA → Done

Both are Done.

Both contribute to sprint velocity.

But one clearly consumed far more effort.

Status bounce analysis helps expose these hidden workflow patterns.

Another interesting use case: Automation Monitoring

Many Jira automations assume issues move forward through a workflow.

When issues repeatedly return to earlier statuses, those assumptions can break down.

We've seen teams use StatusBounces() to identify:

• Repeated approval cycles

• Recurring review failures

• QA rejection loops

• Workflow inefficiencies

• Unexpected automation behavior

before those issues become larger process problems.

Curious how common this is?

Try running a bounce analysis on one of your projects.

I'd be interested to know:

Which status in your workflow do issues bounce back to most frequently?

QA?

Code Review?

Waiting for Customer?

Something else?

Share your findings below. I'm curious whether different teams see similar patterns.

[MeghnaP_LogicLemur Labs]

For anyone interested in trying the StatusBounces() function, it's available as part of StatusClock for Jira Cloud.

StatusClock provides several workflow analytics and JQL capabilities, including:

✅ StatusBounces() - Find issues repeatedly returning to the same status

✅ BusinessDaysInStatus() - Query issues based on business days spent in a status

✅ StatusEntryDate() - Find when an issue entered a status

✅ Time-in-status reporting focused on working days rather than calendar days

You can explore the app here:

https://marketplace.atlassian.com/apps/331619116/statusclock-visual-status-age-bottleneck-tracker-for-jira

I'm also happy to hear about workflow challenges you're trying to solve. If there's a reporting or JQL gap you've run into in Jira, drop a comment below and I'll see whether there's already a solution or something we should consider adding.