Birkan Yildiz _OBSS_ Atlassian Partner

Thanks a lot, glad it resonated @Elena_Elevatic Exactly, history helps you see changes, baselines help you prove them. Appreciate the feedback!

Hi You can achieve this natively by using automation rules and custom fields. However, while these rules work for basic needs, native automation has significant limitations for enterprise reporting. Native Jira doesn't support custom calendars. This means it cannot exclude weekends, holidays, or non-working hours, which…

Hey @Veena Kunchala Welcome to the Community! To recover the original format without manually parsing JSON and open using a 3rd party app, you can use Historian - History Explorer for Jira. Our app includes a Field-Based View that automatically renders this raw ADF history back into readable rich text. You can also export…

Hey Yujia, That is a more complex situation. If your child issues are fully populated but the progress bar remains empty, the cause likely lies in specific project-level configurations or background settings that can be difficult to pinpoint without seeing the exact environment. Best, Birkan

Hey @Yujia Ou Welcome to the Community! The reason your Epic’s progress bar is empty is that Advanced Roadmaps (Plans) uses a bottom-up aggregation called Roll-ups. It ignores the time tracking values set on the Epic itself and instead sums the values of its child Stories and Tasks. If those child issues are unestimated or…

Hey @Divya Sudhakar _US - ADVS_ While ScriptRunner is a powerful tool, calculating accurate time durations requires complex scripting to parse the change history log and account for working calendars (excluding weekends and holidays). If you are open to using a marketplace app, Timepiece - Time in Status for Jira has a…

Hey @Bob Scudder Welcome to the Community! Getting a consolidated view for monthly status meetings without coding is a top priority for many managers. Native gadgets often require you to stitch multiple charts together to get this level of detail. If you are open to using a third-party app, Timepiece - Time in Status for…

I am glad that the article is helpful for you. Also, thanks a lot for the contribution.

Hey @ckopanon Native Jira gadgets can give you a rough idea, but they are often limited because they calculate time 24/5 (including nights) and don't always give you a precise "average" number for a specific custom timeframe like the last 30 days. Timepiece - Time in Status for Jira's Duration Between Statuses report is…

Hey @Giridhar Ujjinappagari Welcome to the Community! That's the biggest challenge with Jira Automation. It's great for new triggers, but it can't look back at your old issues to calculate durations retroactively. Timepiece - Time in Status for Jira has a report that solves this using your existing issue history. It’s…

Hello @Raheem Pillay You are absolutely right. Native JSM gadgets are often limited to basic counts or simple lists. When you want to visualize detailed process metrics or performance trends on a dashboard, you usually need a dedicated app. Full disclosure, I'm on the team that makes Timepiece - Time in Status for Jira,…

Hello @Seamus Largey , First, welcome to the Community! Unfortunately, there is no sustainable way to force the Printable View HTML to serialize multi-line data correctly using Excel’s native scraper. To solve this permanently and ensure all your future reports are clean, you need a solution that pulls data directly from…

Hey @Ron Sethman Welcome to the Community! If you are open to use a 3rd party app, a flexible reporting app is the best way to get the correct data immediately. Timepiece - Time in Status for Jira solves this problem. Its Duration Between Statuses report doesn't rely on the Resolution field or a specific workflow path.…

Hey @David Martínez López , Your best bet with native features is Jira Automation. However, it won't be retroactive, and it will be hard to maintain and require manual calculation. I know you said you are not looking for a marketplace solution, but I am sharing a good fit, just in case. If you want to avoid the complex…

Hi @Radia Dev Thanks a lot for your kind words. I hope built-in options will provide what you need. 

Hey @Zoe N_ The "Days in column" feature is specific to Jira Software's Scrum and Kanban boards. Unfortunately, it is not available for boards in company-managed Business projects. If you need to track how long a work item sits in a specific status for these projects, a Marketplace app is the best alternative. Timepiece -…

Hey @Radia Dev While, as mentioned in the other answers, your request could easily be met using the WAS IN operator in JQL, you noted that the field in question is a custom field. In this case, I'd like to suggest a specific third-party app: Historian - History Explorer for Jira. By using Historian, you can quickly view…

Hey @Naresh Lalchandani That's a great question. Getting the exact date of when an issue first reached a specific status (which often marks the initial assignment) is difficult with native reports. People often try to use automation to stamp a custom field, but that doesn't work for your historical data. If you are open to…

Hey @Pratik Acharya Welcome to the Community! Managing a team of 20+ engineers is exactly the Rubicon where native Jira reporting often stops being enough. You need granular data on flow and efficiency, not just simple burn-down charts. For a tech leader, the most valuable reports are usually centered around Cycle Time,…

Hey @Vando Goncalves _e-Core_ Here is another angle you might find helpful. Calculating average Resolution Time in SQL means you are calculating based on a 24/7 clock. A standard Datediff includes nights and weekends, which skew your metrics. If you are open to use a marketplace app, Timepiece - Time in Status for Jira is…

Hey @Licenses Welcome to the Atlassian Community. That's a very common request. While you can try to create a custom field and populate it using automation, it can be tricky to maintain and, most importantly, it won't work for your historical issues without running complex bulk updates. Timepiece - Time in Status for Jira…

Hey @Varvara K_ Native Jira dashboards don't have a built-in field that auto-calculates "elapsed time" retroactively without complex automation. Timepiece - Time in Status for Jira’s Duration Between Statuses report is perfect for this. It allows you to define a metric by simply selecting a starting point, such as Issue…

hey @Jack Young Yes, it’s fully compatible with Jira Product Discovery. You can test it at no cost by downloading an evaluation license. Let me know if you have any further questions. 

Hey Bill, Thanks for noticing. Just updated the reply. 

Hi @Jack Young Yes, this is definitely possible. Since you are using a custom field ("Second Status") to track this parallel workflow, standard status reports won't catch it, but a marketplace app can. Timepiece - Time in Status for Jira is perfect for this use case. It features a specialized report called "Any Field…

Thanks Seán, glad to hear that. 

Hi @Seán Ó hAnnracháin First of all, welcome to the Community. You are asking all the right questions. The Control Chart is one of the most confusing native reports in Jira, and you've correctly identified why—it mixes calendar time for display and (sometimes) working days for calculation. Let's break down the math to get…

Hello @J B That's an excellent question. I’ll suggest a different approach to address this problem of yours. A simple and powerful way to handle this is to use your Jira workflow as your "stopwatch," which avoids adding a new, complex UI. Here is how: When you start work on the issue, transition it to an "active" status,…

Hey @kkostic , That's a great question, and it's one of the most common and frustrating reporting challenges in Jira. To answer your question: Native Dashboards have a "Time in Status" gadgets, but they show averages for all issues. They don't provide the "per-issue" breakdown you're looking for in an exportable list.…

Hey @Kristine Sube , You're likely discovering, native JSM reports and SLAs are great for tracking total time (like Time to Resolution), but they aren't designed to easily show the granular time spent in each individual step of an internal process or playbook. For that level of stage-by-stage measurement, a dedicated…