6 Metrics Every Support Team Should Track in Jira
Closing hundreds of tickets every month sounds productive. But it doesn't necessarily tell you whether your support process is actually getting better.
The problem usually isn't a lack of data. Jira is already collecting plenty of it. The harder part is figuring out which numbers are actually useful.
For most support teams, six metrics can tell you a lot about what's happening:
- First Response Time
- Resolution Time
- Waiting Time
- Reopen Timing
- Aging WIP
- SLA Compliance
Each one answers a slightly different question.
How quickly are we picking up new requests? How long does it really take to resolve them? Where are tickets spending most of their time? Are resolved tickets staying resolved? Is the backlog getting healthier or quietly growing? And, most importantly, are we meeting the service levels we've promised?
Let's look at each metric using Time Metrics Tracker | Time Between Statuses.
1. ⚡ First Response Time: How quickly do we pick up a request?
What is it?
The time between a request arriving and your team taking its first meaningful action. In Jira, this is often the move from a new-request status to In Progress or Acknowledged.
Why does it matter?
It's one of the first things a customer notices. A slow response can damage trust even if the eventual solution is good. Internally, it can also be an early sign that the queue is understaffed or that triage is starting to fall behind.
How do you measure it in Jira?
Create a time metric from the "new request" status to the "first pickup" status — for example, Open → In Progress. The app uses each ticket's status history to calculate the actual duration, so you're looking at real response times across the queue rather than estimates.
💡 Tip: Apply a work schedule so nights and weekends don't inflate the numbers. Four hours during business hours and four hours across a weekend are obviously not the same thing.
2. 🏁 Resolution Time
What is it?
The total time it takes to resolve a request — commonly Created → Resolved — while excluding the time when your team isn't actually responsible for moving it forward.
Why does it matter?
Raw resolution time can make a support team look slower than it really is. Imagine a ticket sitting in Waiting for Customer for three days. That delay isn't something the agent can control. Measuring net resolution time gives you a much fairer view of actual service speed.
How do you measure it in Jira?
Set up a Created → Resolved metric and use the pause on a status option to stop the clock while the ticket is in Waiting for Customer. This gives you active handling time instead of counting customer delays as team work.
💡 Tip: It can be useful to keep both versions: one showing total resolution time and another showing active time only. The difference between them can tell you a lot about where the process is slowing down.
3. ⏳ Waiting Time
What is it?
The amount of time a ticket spends not actually being worked on — for example, sitting in Waiting for Customer, Pending Approval, or On Hold.
Why does it matter?
This is often where the answer to "Why are we taking so long?" is hiding.
Sometimes the support team is moving quickly, but tickets spend most of their lifecycle parked somewhere, waiting for a customer, an approval, or another team. If you can't see that time separately, it's easy to blame the wrong part of the process.
How do you measure it in Jira?
There are two useful ways to look at it. Using both gives you a more complete picture.
Option A — measure waiting time directly.
Create a dedicated metric that tracks the waiting period itself. For example, start it at the first transition to Waiting for Customer and end it at the first transition to the next active status (Waiting for Support, In Progress, or Done, depending on your workflow).
Apply your support work schedule so the metric counts business hours only. Now "time waiting on the customer" becomes a number you can trend over time and set Warning/Critical limits for, rather than just a hidden part of resolution time.
Option B — look at waiting as a share of the whole lifecycle.
Set up a metric covering the full ticket lifecycle — for example, a Lead Time metric from Created → Done — and open the Status Contribution Chart.
This breaks the total time down by status and shows what percentage of the journey is spent in each one. If Waiting for Customer or Pending Approval takes up a large part of the chart, you've probably found the real bottleneck.
You can then drill down into the tickets behind that number.
4. 🔁 Reopen Timing
What is it?
How long a ticket stays resolved before coming back. In Jira, this could be the time between Resolved and Reopened, or Done and In Progress.
Why does it matter?
Reopens can tell you something about the quality of the resolution. A ticket that comes back may have been closed too early, misdiagnosed, or not fully fixed.
Looking at the timing helps you spot premature closes and see whether they happen more often with particular issue types, agents, or request categories.
How do you measure it in Jira?
Create a time metric from the resolved status back to the reopened status — for example, Resolved → Reopened.
This tells you how long the ticket stayed closed before returning and lets you drill into the tickets that bounced back.
5. 📈 Aging WIP: Is the backlog building?
What is it?
Work in progress that's getting older — either because open tickets are accumulating faster than they're being closed, or because individual requests are quietly spending too long in the workflow.
Why does it matter?
A team can meet every SLA today and still be heading toward a problem.
If the backlog is getting older, delays can become tomorrow's SLA breaches. Aging WIP gives you an earlier warning that the flow is under pressure.
How do you measure it in Jira?
The WIP Run Chart is designed for this. It plots two lines over time:
- WIP Count — how many tickets are in progress each day
- Avg WIP Age — how old those in-progress tickets are on average
Looking at the two together helps you understand what's going on:
- Count flat, age flat → healthy, predictable flow.
- Count rising and age rising → the team is taking on more work than it can finish, so work is stacking up.
- Count flat but age climbing → a classic hidden bottleneck. The queue doesn't look bigger, but the same tickets are sitting there getting older. They may be stuck in review, QA, or waiting.
That's a pattern that SLAs might not warn you about until the problem is already visible to customers.
6. ✅ SLA Compliance
What is it? The share of tickets that met their agreed time targets — for example, "resolved within 48 business hours."
Why it matters: This is one of the clearest ways to show customers and stakeholders whether your service is meeting expectations. It also helps you understand whether SLA breaches are occasional exceptions or becoming a recurring problem.
How to measure it in Jira: Time Metrics Tracker adds Warning and Critical time limits to custom metrics. Tickets can be color-tagged yellow or red as they approach or cross a threshold. This is useful for statuses and transitions that native SLAs don't cover, as well as Jira Software projects where native JSM SLAs don't apply.
💡 A few practical tips for improving support performance
- ⏱ Apply business hours consistently — otherwise nights, weekends, and holidays can make SLA and response numbers misleading.
- 🔍 Separate active time from waiting time — it often changes the entire conversation around "slow" support.
- 📉 Review WIP trends weekly rather than relying on daily snapshots. Trends usually tell you more than a single number.
- 🧩 Put the key metrics on a dashboard so changes become visible before the monthly review.
- 📤 Export to XLSX/CSV when you need to share results with stakeholders or keep an audit trail.
🎯 Final thoughts
You don't need dozens of dashboards to understand your support process. These six metrics can quickly show where you're doing well, where work gets stuck, and what needs attention.
Start with native JSM SLAs, then use time-based metrics to understand what's happening behind the numbers.
Explore the app on the Atlassian Marketplace.
2 comments
