Metric Definition
Backlog age profile
Track from
Issue aging analysis
Issue aging analysis is the practice of grouping open issues by how long they have been unresolved, so you can see whether work is moving or stalling. It turns a single backlog count into an age profile that exposes the items quietly slipping past their service targets. The oldest buckets are where customer trust and team credibility erode first.
7 min read
What is issue aging analysis?
Issue aging analysis is the practice of measuring how long each open issue has been unresolved and grouping those issues into age bands. Instead of reporting a single number such as 240 open issues, it breaks the backlog into buckets: how many are under a week old, how many are one to four weeks old, and how many have been open for more than 90 days. The shape of that distribution tells you far more than the total ever could.
A backlog of 240 issues where most are under a week old is healthy and moving. A backlog of 240 where 80 of them are older than 90 days is a different story. Those 80 are the issues that customers have stopped trusting you to fix, the ones that quietly miss every service target, and the ones that make a renewal conversation awkward. Aging analysis surfaces them before they surface themselves.
The analysis applies anywhere work queues up and waits: support tickets, bug reports, engineering defects, compliance findings, and audit actions. The underlying question is always the same. Of everything still open, how old is it, and is the oldest part of the queue growing or shrinking. A queue can have a flat total while the average age climbs, which is the early warning that resolution is falling behind intake.
Age is measured from the created date, not from the last time someone touched the issue. Re-dating an issue when an agent adds a comment hides the very problem aging analysis exists to expose. If you need to track active versus idle time separately, add a distinct idle-age field rather than resetting the original age.
How to calculate issue aging analysis
For each open issue, subtract the created date from today to get its age in days. For resolved issues you are studying retrospectively, subtract the created date from the resolution date instead. Then assign every issue to an age bucket and count how many fall into each one. The output is a distribution, not a single figure.
Choose buckets that match your service targets. If your stated resolution target is seven days, a 0 to 7 bucket separates issues that are still inside target from those that have breached it. A worked example: an issue opened on 1 June, viewed today on 20 June and still open, has an age of 19 days and lands in the 8 to 30 day bucket. Track the count and the percentage of the backlog in each bucket over time to see whether the profile is ageing or staying fresh.
- 1
Created date
The point the issue was opened. Use the original creation timestamp and never overwrite it when the issue is reassigned or commented on.
- 2
Resolution date or current date
For closed issues, the date they were resolved. For open issues, today. This is the end point of the age calculation.
- 3
Age in days
The difference between the two dates above. This is the raw number that determines which bucket an issue belongs to.
- 4
Age buckets
The ranges you sort issues into, typically aligned to service targets, for example 0 to 7, 8 to 30, 31 to 90, and 90 plus days.
Issue aging analysis in a metric tree
An ageing backlog is never the root cause. It is the visible symptom of an imbalance between how fast issues arrive, how fast they are resolved, and how work is prioritised. A metric tree decomposes the age profile into the forces that produce it, so you treat the cause rather than the count.
Metric tree insight
When the oldest bucket grows while intake is flat, throughput or prioritisation is the cause, not workload. KPI Tree connects each branch to the team that influences it and assigns RACI ownership, so the accountable owner is the first to know when the 90 plus day bucket starts climbing. The verified impact loop then checks whether a triage change actually drained the old bucket or just reshuffled it.
Issue aging analysis benchmarks
Healthy backlogs concentrate in the youngest buckets and taper sharply. The rough guide below describes what share of an open backlog typically sits in each age band for a well-run support or engineering queue. Targets vary by issue type, so treat these as starting points and tighten them against your own service commitments.
| Age bucket | Healthy | Watch | At risk |
|---|---|---|---|
| 0 to 7 days | 55% or more | 40% to 55% | Below 40% |
| 8 to 30 days | 20% to 30% | 30% to 40% | Above 40% |
| 31 to 90 days | 10% or less | 10% to 20% | Above 20% |
| 90 plus days | 3% or less | 3% to 8% | Above 8% |
A low oldest-bucket percentage can be misleading if the total backlog is large. Three per cent of 2,000 open issues is still 60 issues that have waited a quarter of a year. Always read the percentage alongside the absolute count so a growing queue does not hide its tail.
How to improve issue aging analysis
Improving the age profile means draining the old buckets while preventing new issues from ageing into them. That takes a mix of focused clearance work and changes to how the queue is prioritised day to day.
Run a dedicated aged-issue sweep
Carve out regular time to work only the oldest bucket. A weekly block where the team resolves or formally closes the issues over 90 days old stops the tail from compounding while normal intake continues elsewhere.
Triage by age, not just severity
Severity alone lets low-priority issues age indefinitely. Add an ageing rule so any issue crossing 30 days is automatically reviewed and either escalated, reassigned, or closed with a clear reason.
Assign an owner to every aged issue
Old issues often have no clear owner, which is why they stall. Give each one a named owner accountable for the next step, so nothing sits in the queue waiting for someone to claim it.
Alert before issues breach the target
Notify the owner when an issue is approaching a bucket boundary rather than after it has crossed. Acting at day five on a seven-day target keeps issues out of the breached band entirely.
Common mistakes when tracking issue aging analysis
- 1
Resetting the clock on every update
Re-dating an issue whenever someone comments makes a stale backlog look fresh. Always age from the original created date and track idle time as a separate field if you need it.
- 2
Reporting only the average age
A single average hides the tail. A queue with most issues fresh and a handful ancient can show a reasonable mean while a small group of customers waits months. Read the full distribution.
- 3
Ignoring closed-but-unresolved issues
Bulk-closing aged issues to clean the chart does not resolve them. If they reopen, they return with their original age intact. Track reopen rate alongside aging so you do not reward hiding the problem.
- 4
Using one bucket scheme for every issue type
A 90-day-old feature request and a 90-day-old security bug are not equivalent. Segment aging by issue type so buckets are read against the right service target rather than a single blanket rule.
Related metrics
Average Resolution Time
Customer Support Metrics
Metric Definition
Average Resolution Time = Total Resolution Time Across All Tickets / Total Tickets Resolved
Average resolution time measures the mean elapsed time from when a support ticket is created to when it is fully resolved and closed. It captures the end-to-end customer experience of getting an issue fixed, encompassing wait times, agent work time, escalations, and any back-and-forth exchanges required to reach a solution.
Ticket Volume
Customer Support MetricsMetric Definition
Ticket Volume = Total New Tickets Created in Period
Ticket volume is the total number of new support tickets created within a defined period. It is the fundamental demand metric for support operations, determining staffing requirements, budget allocation, and the urgency of self-service and product quality investments.
Escalation Rate
Customer Support MetricsMetric Definition
Escalation Rate = (Escalated Tickets / Total Tickets Handled) x 100
Escalation rate measures the percentage of support tickets that are transferred from one tier or team to a higher tier or specialist group for resolution. It reflects the gap between the issues customers raise and the ability of frontline agents to resolve them, making it a key indicator of agent readiness, process maturity, and product complexity.
First Response Time
Customer Support MetricsMetric Definition
FRT = Total First Response Times / Total Tickets With a First Response
First response time measures the elapsed time between a customer creating a support ticket and receiving the first substantive response from a human agent. It is the metric that shapes the customer's initial impression of the support experience and sets the tone for the entire interaction.
Metric decomposition
Metric Definition
Break issue aging analysis into its underlying age buckets and inflow and resolution drivers so you can see what is pushing the backlog older.
Metric trees for operations teams
Metric Definition
See how operations teams place backlog age profile alongside throughput and resolution metrics to keep the queue under control.
Turn your backlog age profile into owned action
Build issue aging analysis as a metric tree in KPI Tree, with intake, throughput, and prioritisation as branches and a named owner on each. When the oldest bucket starts to climb, the accountable owner is alerted first and the verified impact loop confirms the fix actually drained it.
