How to Measure Jira Cycle Time Without Counting Weekends (and Holidays)

[#1]

If you track Cycle Time, Lead Time, or Resolution Time in Jira, you've almost certainly run into a number that made you stop and double-check your sanity.

Picture this: a ticket moves to In Progress on Friday at 5:00 PM and gets marked as Done on Monday at 9:00 AM. Jira's raw issue history logs that as roughly 64 hours. But nobody touched that code over the weekend — the actual work done was maybe a few minutes of cleanup.

That gap isn't a bug, and your team isn't bad at logging time. It's simply the stark difference between calendar time and working time. And it quietly ruins almost every status-duration metric engineering and product teams rely on to spot real bottlenecks.

Let's break down what's actually happening under the hood, why built-in Jira reporting falls short here, and how you can start measuring pure, honest working time using Time Metrics Tracker | Time Between Statuses.

The core problem: elapsed time counts hours nobody worked

When you measure how long an issue spends between two statuses, the simplest calculation is basic subtraction: timestamp B minus timestamp A. That gives you raw elapsed (calendar) time, which indiscriminately includes:

• Weekends and public holidays
• Overnight hours
• Time zone gaps across distributed teams
• Daylight saving shifts (twice a year, an hour magically vanishes or appears)
• Waiting statuses where an issue was parked, like Waiting for Customer or Blocked

None of that reflects actual effort, yet all of it inflates your metrics.

To make matters worse, this distortion isn't even across tickets: an issue started on a Friday looks significantly slower than an identical issue started on a Monday. Same effort, drastically different numbers. This makes sprint-over-sprint comparisons and team benchmarks unreliable.

The question you should be asking isn't "How many calendar hours passed?" It's "How many working hours were spent on the parts that actually mattered?"

First, decide where the clock starts, stops, and ticks

Before setting up any metrics, two decisions will make or break your data:

• Start and stop points. This is the boundary between Cycle Time and Lead Time. Cycle Time usually ticks from the moment active work begins (e.g., entering In Progress) to completion. Lead Time starts the second a request is logged, capturing queue time in the backlog. Same ticket, completely different numbers — all because the starting line moved.
• Which hours count as "working" hours. Once start and stop are locked in, you have to decide: does the clock keep running overnight, on weekends, and during hold statuses? Most teams skip this step — and that's where the "weekend penalty" hides.

Why Jira's native reporting leaves a gap

Jira offers built-in tools for tracking time, but each runs into clear limits:

• Control Chart (Cycle & Lead Time). Great for a quick snapshot on a single board. However, it's strictly scoped to that board, measures calendar time, lacks flexible per-metric work calendars, and can't strip out specific waiting statuses. The weekend problem lands right in the middle of your chart.
• JSM SLAs (Resolution Time). Service Desk SLAs handle working calendars well and pause cleanly on Waiting for Customer. But that logic is locked inside Jira Service Management and designed around SLA goals — you can't easily reuse it for arbitrary status transitions in standard Jira Software projects.
• JQL + CSV Export. JQL lets you filter by dates, but it can't calculate durations between specific transitions. You end up exporting raw change histories and building fragile spreadsheet formulas by hand.

The common theme: outside a single board or JSM's SLA framework, status-to-status durations count raw elapsed time unless you build custom working-hours logic yourself.

How to measure accurate working time with Time Metrics Tracker

Time Metrics Tracker solves this by analyzing your Jira status-transition history and calculating duration against work schedules you define — ignoring non-working hours entirely.

Here's how to set it up step-by-step:

Step 1 — Create a work schedule

Open the app from your Jira sidebar. From the report screen, click the three dots (⋯) in the top-right corner → Configuration, then select Work Schedule.

This is where you tell the app what "working hours" actually mean for your team:

• Time zone: Evaluates metrics against your team's local time, not the global Jira server default.
• Work days: Select active working days (e.g., Monday–Friday).
• Work hours: Set team shift times (e.g., 09:00–17:00), or toggle 24/7 coverage for round-the-clock ops.
• Breaks: Exclude lunch breaks or handoff windows so they don't count toward active time.
• Holidays: Add regional or company holidays, complete with an Annually toggle so recurring dates roll over automatically.

Step 2 — Define metrics for any status pair

Back in Configuration, click Time Metrics to add a new rule. You aren't limited to generic Cycle or Lead Time — you can measure any stage in your workflow: code review duration, QA turnarounds, approval wait times, or initial response speed.

For each metric, configure:

• Time metric name: A clear label (e.g., Resolution Time or Code Review Duration).
• Project: The Jira project this metric applies to.
• Work schedule: Select the schedule created in Step 1 so the clock runs only during active hours.
• From status → To status: Set your start and stop triggers (you can also require specific transitions if needed).
• Exclude statuses (optional): Pause the clock when tickets sit in designated idle statuses (e.g., exclude Waiting for Customer so your Resolution Time reflects pure team effort).
• Warning & Critical limits (optional): Set thresholds to flag stalled issues automatically before they derail a sprint.

Step 3 — Reuse schedules across teams

Schedules are modular. Create a calendar once, name it, and link it across multiple metrics. Because each schedule holds its own timezone, working hours, and holidays, cross-functional teams can work side-by-side without skewing each other's metrics.

Example: A New York Design team, a 24/7 Support crew, and an engineering team in Europe can each run on tailored calendars. Set up Cycle Time for Dev and Resolution Time for Support, attach their respective calendars, and your metrics remain fair internally and honest across teams.

What honest numbers look like in practice

Once non-working hours are stripped out, your reports finally reflect actual effort:

• Real bottlenecks, not weekend lag. Easily tell if an issue was genuinely stuck in Code Review or if it was just waiting around for Monday morning.
• Fair benchmarks. Tickets picked up on Friday afternoon and Monday morning are measured on the exact same scale, keeping team comparisons objective.
• Trustworthy trends. Group performance by week or month to answer the real question — "Are we actually shipping faster?" — without holiday noise skewing the trendline.
• Defensible reporting. When leadership asks why Resolution Time spiked, you can pinpoint the exact workflow stage that expanded, rather than blaming the calendar.

Time Metrics Tracker doesn't automagically fix a broken workflow — but it measures it accurately, giving you the real data needed to make meaningful process improvements.

Takeaway

A status duration metric is only as reliable as the hours it counts. Before assuming your team's velocity is dropping, check if your charts are counting weekend downtime, overnight gaps, or customer response delays.

Define your start/stop points, lock in your working schedules, and apply those rules consistently.

If you'd like to test this against your own Jira workspace, you can grab Time Metrics Tracker on the Atlassian Marketplace.

Have questions on mapping transition statuses, excluding waiting times, or configuring schedules for custom workflows? Leave a comment below — happy to help!