Defect lead time and reopen rate on dashboards show incorrect values after workflow changes

ALM Atlassian Jira Software
, , , , , , , ,
1

Our QA dashboard for defect lead time, reopen rate, and resolution SLA is showing unreliable numbers since we updated our bug workflow. The dashboard uses built-in gadgets pulling from Resolution Date and Status fields. After we added a “Pending Retest” transition, reopened bugs now show inflated lead times-some defects report 45+ days when they were actually resolved in 3 days.

Example calculation from gadget:


Lead Time = Resolution Date - Created Date
Reopen Rate = COUNT(Status changed to Reopened) / Total Resolved

When a bug moves to Reopened, the Resolution Date clears, but when it resolves again, the gadget calculates from the original Created Date, not the reopen timestamp. Our QA SLAs depend on accurate metrics, and we export this history for monthly executive reports. Is there a post-function we’re missing, or do we need custom fields to track reopen cycles?

2

For reopen rate, you need to distinguish between “defects that reopened at least once” vs “total reopen events.” The built-in gadgets don’t handle this well. We created a custom JQL gadget that queries:


status changed TO Reopened DURING (startOfMonth(), endOfMonth())

Then divide issue count by total resolved issues in that period. This gives you unique defect reopen rate, not event count. For executive reports, we export the issue history via REST API and calculate metrics in Excel.

3

We faced this exact issue in Jira 8 after adding workflow states. Our solution was to add a post-function on the Resolve transition that sets a custom date field “Last Resolution Time” with current timestamp. Then the dashboard gadget uses that field instead of the native Resolution Date. For reopen rate, we track status change history via a scripted field that counts transitions to Reopened status.

4

The JQL approach works for reopen rate, but I’m still stuck on lead time accuracy. If I add a “Last Resolution Time” custom field, do I need to update it on every resolve transition, or just the final one? Our workflow has “Resolved” and “Closed” states, and bugs can reopen from either.

5

That makes sense for lead time, but how do you handle the reopen rate calculation? Our current gadget just counts how many times Status changed to Reopened, but it doesn’t normalize by the number of unique defects. If one bug reopens 3 times, it skews the rate. Do you use a calculated field or export to external BI tools?

6

Here’s a comprehensive solution addressing all your KPI concerns:

Resolution Date Behavior on Reopen: The native Resolution Date field clears when a bug transitions to any “reopened” status category. This is hardcoded Jira behavior and can’t be changed via workflow configuration. To track accurate resolution timestamps across reopen cycles, create a custom DateTime field called “Actual Resolution Timestamp” and set it via post-function on your Resolve transition:


issue.setCustomFieldValue(customField, new Timestamp(System.currentTimeMillis()))

This field persists through reopens, giving you the last resolution time.

Dashboard Gadgets Using System Fields: The built-in “Average Age” and “Resolution Time” gadgets calculate from Created Date to Resolution Date, ignoring reopen periods. Replace these with custom JQL gadgets or use a marketplace plugin like “Custom Charts” that can query your “Actual Resolution Timestamp” field. For lead time, calculate:


Actual Lead Time = Actual Resolution Timestamp - Created Date

Workflow Post-Functions Affecting Timestamps: Add these post-functions to your workflow:

  1. On “Resolve” transition: Set “Actual Resolution Timestamp” to current time
  2. On “Reopen” transition: Set a “Reopen Count” number field to increment by 1 (use a scripted post-function)
  3. On “Close” transition: Optionally set a “Closure Timestamp” if you track Resolved vs Closed separately

This ensures your timestamps reflect actual work completion, not system field behavior.

Defect SLAs and KPIs for QA Teams: For SLA compliance, use Jira Service Management SLA features or a marketplace SLA plugin that can pause timers during specific statuses. Configure SLA goals to exclude “Pending Retest” and “Reopened” states from the active timer. This gives you accurate “time to resolution” metrics that align with QA team performance goals.

For reopen rate KPI, use this approach:

  • Unique Defect Reopen Rate: `COUNT(DISTINCT issue WHERE status changed to Reopened) / COUNT(DISTINCT resolved issues)
  • Reopen Event Rate: `SUM(Reopen Count field) / COUNT(resolved issues) Track both metrics-unique defect rate shows quality issues, event rate shows rework volume.

Exporting History for External Reporting: For monthly executive reports, export via Jira REST API using the changelog endpoint:


GET /rest/api/2/issue/{issueKey}/changelog

Parse the history for status transitions, calculate metrics in your BI tool (Excel, Tableau, Power BI), and join with your custom timestamp fields. This gives you full control over lead time calculations, reopen cycle analysis, and trend reporting without relying on dashboard gadget limitations.

Implementation Summary:

  1. Add custom fields: “Actual Resolution Timestamp” (DateTime), “Reopen Count” (Number)
  2. Update workflow post-functions to populate these fields
  3. Replace built-in gadgets with custom JQL queries or marketplace chart plugins
  4. Configure SLA rules to pause during non-active states
  5. Export changelog data monthly for executive reports

This setup ensures your defect KPIs accurately reflect QA team performance and provide reliable data for SLA compliance and management reporting.

7

The Resolution Date field behavior is standard-it clears on reopen by design. If you want to track cumulative time excluding reopen periods, you’ll need a custom field like “Active Resolution Time” that accumulates only while the bug is in active fix states. Gadgets using native Resolution Date won’t account for reopen cycles automatically.