nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Best time tracking app

mborinstein

I am looking for a third-party app that will help our leadership understand how much time engineers are spending on tickets each month. My two MUST HAVES are:

1. Grouping by epic: For each epic, how much time did each engineer spend on tickets within that epic

2. NON-CUMULATIVE TIME: If an engineer worked on a ticket from November 1 - 3, and they picked up another ticket from November 2-3, I do not want the total time spent across both tickets (3 days + 2 days). I want to know that in November, they spent 3 business days working on tickets.

I ideally also want an app that will let me customize what "time spent" working on a ticket means (i.e. being able to only look at the time from when a ticket moved to In Progress to when it moved to Done).

I have found some apps that give me pieces of this (Timepiece, Time in Status) but the non-cumulative time part seems hard to find. Any recommendations?

Accepted answers

All comments

Robert_lryjhw

That’s a really thoughtful and well-defined question — and honestly, one that a lot of engineering teams struggle with once they scale. 👏

You’re absolutely right — most marketplace apps like Timepiece, Time in Status, or Tempo Timesheets tend to give you cumulative time logs, which are fine for reporting effort but not great for understanding actual working days spent within a time window.

From experience, what you’re describing — “non-cumulative time per engineer within epics” — usually requires something that can analyze state transitions + timestamps rather than raw time logs. carpet cleaning in tracy

A few ideas worth exploring:

Custom Jira automation + reporting via eazyBI or Custom Charts: You can pull issue histories and calculate distinct “In Progress” dates per user. It’s a bit of setup, but it gives you exactly what you’re after — calendar days of activity rather than total logged time.

Tempo Timesheets (advanced filtering): It’s not perfect for non-cumulative time out of the box, but if you combine Tempo with Automation for Jira (to track state changes as custom fields), you can approximate it.

WorklogPRO might be another one to test — it supports aggregating worklogs by user and epic and can filter based on specific status durations.

If you want to go deeper, you can also export your issue histories via Jira REST API and process them in a small Python or Google Sheets script — compute “distinct active days per user per epic.” That’s often the cleanest approach if you don’t want to overpay for heavy marketplace apps.

Totally get what you’re going for though — leadership doesn’t need inflated “effort hours,” they need real working footprint data. Love how clearly you’ve defined that difference. 👌

Iryna Komarnitska_SaaSJet_

Hi @mborinstein ,
You’re essentially looking for two things:

Epic-level rollups by engineer, and
Distinct business days an engineer worked in a month (not the sum of overlapping time across multiple issues).

For #2, that’s fundamentally a worklog question rather than a status-time question. Status-based tools read Jira changelogs; they can tell how long an issue sat in In Progress, but they can’t infer whether two issues were worked in parallel by the same person. If both issues are In Progress on the same dates, changelog-based reports will double-count unless your workflow enforces only one active item at a time.

If you want to stay with status-time, the key is process discipline:

Pause anything not actively being worked. When an engineer switches context, move the first issue out of In Progress (e.g., to On hold).
Review your workflow. You may need an explicit Paused/On hold state (or similar) so the lifecycle reflects reality.

I’m on the Time in Status team, and here’s how you could build the epic/assignee report with our Pivot view (status-time approach):

Rows: Epic → Issue → Assignee
Columns/Values: Spent time in statuses
Filters: Date range = your target month; project(s)/team as needed
Totals: Show totals per Epic; optionally include Epic age

This gives leadership a clear breakdown of time-in-status by epic, issue, and engineer.

For your “non-cumulative days” requirement specifically:

If this is a hard requirement, you’ll get the most reliable results with worklogs, because they can be analyzed as distinct working days per person per month across all issues (i.e., Nov 1–3 for Issue A and Nov 2–3 for Issue B count as 3 days total, not 5).
If you prefer status-time, the closest proxy is to enforce that only one issue per engineer can be In Progress at a time (using the On hold pattern above). That prevents double-counting and makes status-time reports much closer to “distinct days.”

Happy to share a sample Pivot configuration or a quick walkthrough if that helps. Hope this clarifies the trade-offs!

Michał Kowalewski_SolDevelo

Hi @mborinstein

For points 1 and 2, our marketplace application Worklogs - Time Tracking, Time Reports, Timesheets should meet your expectations.

Grouping by epic.

In the Worklogs app, you can group your data in many various ways, including the possibility to display Epics and their child Jira work items (tasks, stories, etc.). For example, in the screenshot below, I display the following report: Project → Epic → Jira work items.

Based on this information, you can see how much time was spent on each epic and its child issues. Of course, instead of the Project in the first column, you can display your employees to see how they log the time and where. You can also display a different date range based on your needs.
NON-CUMULATIVE TIME.

In the app, you can easily display data and see how employees log their time. You will obtain information about what an employee worked on on a given day and what they worked on the next day. What's more, in the report, you get Summary to see if indeed 8h were spent on the particular day. For example, in the screenshot below, the employee worked on different tickets between November 1-4, and you can effortlessly get such information in the app:

The only thing you mentioned that our app lacks is the possibility to count the time in status for the Jira work items. You can always display the current status for the tickets in the report, but it won't tell you how long it took to change it from progress to done, for example.

However, many more functions can be useful for you and your team. With Worklogs, logging time and displaying data become very intuitive.

If you have any questions, feel free to reach us, or if you prefer a meeting, please book a demo session. We will be happy to learn more about your use-cases.

Kind regards,
Michał, SolDevelo Team

Mary from Planyway

Planyway for Jira provides a highly visual and flexible platform that can be configured to meet your reporting needs:

You can typically drill down into an epic to see the individual tasks and the assignees.
As for non-cumulative time, you can easily group the report by tasks as well to see what's needed.
Use Planyway's filtering in reporting to only look at tasks that have moved through your "In Progress" to "Done" workflow steps within a given period.

Снимок экрана 2025-11-05 101520.png

Elita Kalāne - eazyBI Support

Hi,

This is Elita from the eazyBI Team.
What you're describing - tracking actual working days per engineer within epics rather than cumulative logged hours - can be achieved with eazyBI.

We have standard/built-in calculations, "Days in transition status" and "Workdays in transition status," that are designed to capture the Days the tickets spent in specific statuses. Another option is to import Issue Cycles that allow you to configure the Issue Cycle based on the Statuses you want to consider (excluding statuses such as "to do" or "Waiting for approval", etc.). Here are some example reports or our Demo Dashboard - https://eazybi.com/accounts/1000/dashboards/7513-age-lead-and-cycle-time

You can group the results based on your requirements, including the Epic level.

With custom calculations, you can also determine the days spent in a status without cumulatively summing the days.

I created a test report on my account and defined a calculated measure that looks at the selected time period and counts only the weekdays (Monday-Friday) where at least one issue was "In Progress". If you select January 2025, this measure will tell you "on how many weekdays in January did assignee have at least one issue being worked on (was in Progress category)?"

So if your team member worked on issues for 15 out of 22 possible weekdays in January, the result would be 15.

Here is an example with results for the previous month:

example-days in status.png

If you're curious what the expression behind the measure looks like, here it is:

NonZero(
Count(
Filter(
-- Get all days in the selected time period
DescendantsSet(
[Time].CurrentHierarchyMember,
[Time].[Day]
),
-- Filter to business days only (exclude weekends)
NOT [Time].CurrentHierarchyMember.Get('Week day name') 
MATCHES 'Saturday|Sunday'
AND
-- Only count days up to today (not future days)
DateCompare(
[Time].CurrentHierarchyMember.StartDate,
Now()
) <= 0
AND
-- Check if any issues were in progress on this day
(
[Measures].[Issues history],
[Transition Status.Category].[In Progress]
) > 0
)
)
)

If you ever consider trying eazyBI for your reporting needs, please don't hesitate to reach out to us directly (support@eazybi.com) for assistance with setting up your reports and guidance on building custom measures.

Best wishes,

Elita from support@eazybi.com

mborinstein

Hi Iryna - if I want to go the worklogs route how would I do that in the Time in Status app?

mborinstein

Hi Mary - Does Planyway require engineers to log time on each ticket or is there an option to base "time worked" on time between statuses?

Mary from Planyway

Do you mean if it is possible to set time worked in advance by the manager?

Iryna Komarnitska_SaaSJet_

Hi @mborinstein ,

No, the Time in Status app only calculates the time spent in statuses. For worklogs, you can find any app on the marketplace that allows you to log work and generate reports on it.

However, you will not be able to perform a retrospective analysis; only an app that analyzes Jira changelogs will allow you to do this.

mborinstein

Hi Elita,

Thank you this is incredibly helpful! I was able to replicate this and am now trying to add the layer of grouping by epic but I'm not sure if it's working. Here is a screenshot of what it looks like when I do so (blocked out some stuff for privacy). You can see that for each assignee it gives me the "Workdays in a Month" total in the Epic row and then gives me other values on the ticket by ticket level. (Workdays in a Month is what I called the custom measure you created).

If you look at the tickets assigned to Lindsay you can see that she has one ticket with 3 Workdays in a Month and another ticket with 20 workdays. Then on the epic level it lists her total as 23. The scenario I'm worried about is let's say she worked on Ticket 1 from October 1 - 20 and Ticket 2 from October 17-20. She only technically worked 20 days but it may be adding that up to 23.

Do you know if I would need to change the custom measure you created to have it calculate how many unique days she worked in any given month on each epic?

To make sure I'm being clear - I'm looking for: If she worked October 1 - 20 on Epic 1 it will list 20 days, and if she worked October 3 - 10 on Epic 2, it lists 7 days on that Epic Row. Thank you! Screenshot 2025-11-07 at 11.34.51 AM.png

eazyBI Support

Hi @mborinstein

Thanks for the follow-up, and I'm glad to see you were able to replicate the same report.

Could you please clarify whether you manually verified the tickets for Lindsay?
When looking at Keith's tickets, they are not being summed (Keith has 9, 7 and 2 days for individual tickets but at the Epic level it shows 9, the overlapping tickets are included in the time period of 9 days), so I am wondering if both tickets for Lindsay indeed overlapped?

You can also reach out to us directly at support@eazybi.com, referring to this Community post if you are not comfortable sharing your data here publicly.

Best wishes,

Elita from support@eazybi.com

mborinstein

Hi Elita,

I submitted a support ticket and referenced our conversation if you want to take a look there! https://eazybi.com/contact/conversations/3133292584

It's titled "FTE custom measures"

Petru Simion [Simitech Ltd.]

Hi @mborinstein ,

This deppends a lot on how you set up your workflows . You need to define what "each engineer spends on a ticket".

Once you defined this you can write your own app that will extract that data.

If you are open to using apps you can use a mix of these two apps, both released by us.

Issue History Dashboard for Jira (Work Item History)

You can filter out data by project and understand how issue was moved in the issue history in different statuses. The Reporter, Assignee, Date of Change and Status fields will allo you to filter out and understand which user was involved and when.

Time in Status Dashboard for Jira

You can filter out data by project and display it in two perspectives, both will show how much each ticket spent on each status as well as how many times the ticket was in that status. Fields Current Reporter and Current Assignee will help you filtering out which reported or worked on the ticket.

Columns Perspective

Rows Perspective

All results are exportable as CSV for you to do more drill down and processing using Excel or the tool of your choice.

Regards,

Petru

Anton from JetHeads_io

Hey!

For point 1 — JetTime fully covers this. You can generate time reports grouped by epic, project, or user, and filter by ticket status (e.g., only "Done" tickets). So you'll see exactly how much time each engineer spent on tickets within each epic.

For point 2, non-cumulative time — that's trickier. No app I know of calculates "unique business days worked" across overlapping tickets out of the box. You'll need a custom solution using a mix of Jira automation and custom scripts to handle that logic.

My recommendation: use JetTime as your base time tracker for reports and grouping, then build the custom non-cumulative logic on top of it yourself.

With JetTime you get:

Time tracking & timesheets with improved Log Work UI and timers
Cost tracking with custom financial fields
Custom metrics (mileage, materials, activity types, etc.)
Reports with PDF & Excel export
Runs fully on Atlassian infrastructure, so data stays inside Atlassian Cloud

👉 JetTime on the Atlassian Marketplace
— Anton, JetTime founder

Vladimir Letiagin

On #2: several people above said it, and it's worth taking seriously: "distinct working days per engineer per month" is only reliable from worklogs. Status time can't tell whether two tickets were worked in parallel, and every workaround here is process discipline that erodes by the second sprint. The eazyBI measure Elita wrote already does the day-counting once the worklogs exist.

The usual objection is that engineers won't log time. That is mostly a friction problem, and the friction is Jira's Log work dialog. A menu bar timer removes most of it: pick the ticket, hit start, hit stop; the entry lands on the ticket as a plain Jira worklog under the engineer's own account, so eazyBI, Tempo or the Worklogs app all see it. Planim Time is one such tracker (Mac / Windows / Linux, free tier without limits): https://time.planim.app/jira. It won't produce the epic/engineer report by itself, but it makes the worklog data that report needs cheap to collect.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud

apps