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; } } }

How to get start and end times for an epic?

paul_h813yj

Hello, I would like start and end times for epic? I have statuses for an epic like "to do", "ready", "in progress", "done" and "closed". How do I get times for when an epic flows through theses states? Particularly, when someone changes the status from "ready" to "in in progress" and when "in progress" to "done". How can I get these time stamps for these states when they change. I like to know how long an epic is "in progress".

I am using Azure Jira v10.3.12.

Thanks,

Paul

Accepted answers

All comments

John Funk

Hi Paul,

You can see the information in the History for the wok item in the Activity section of the work item. If you need it like in a report, could use on of the many apps in the Atlassian Marketplace - some are free and some require payment. But that is the easiest way.

Another way would be to create custom fields and use automation rules to populate the custom fields.

Nishant Paraskar_5se8q0

Hi Paul,

One option is to use the Jira REST API & review the Epic's changelog/history uisng API and another simple way on Jira issue View Screen from History

From there, you can identify when the Epic first moved into an "In Progress" status and when it was finally transitioned to a "Done" status.

If you need to track these dates going forward, I suggest you to create custom fields such as "Epic Start Date" and "Epic End Date" and populating them using Jira Automation whenever the Epic changes status. or by workflow postfunction automation to capture the time when status change.

In DC Jira version you can also refer to Transition tab on Jira View Screen where you can find the transition details but this isn't a available for Jira Cloud,

Anwesha Pan

Hi @paul 👋🏻

In addition to @John Funk and @Nishant Paraskar suggestions, I have one update for you.

If you need those timestamps permanently logged on the epic for future use, you can create custom fields by adding automation rule:

Create 2 new Date/Time Picker custom fields: In Progress Time and Done Time.
Go to Project Settings > Automation and create a new rule:
- Trigger: Issue transitioned
- From Status: Ready
- To Status: In Progress
- Action: New action > Edit issue > Set In Progress Time field to {{now}}.
Create a second rule for the finish time:
- Trigger: Issue transitioned
- From Status: In Progress
- To Status: Done
- Action: New action > Edit issue > Set Done Time field to {{now}}.

Once populated, you can easily use these dates to calculate the exact duration an epic spent in progress.

I hope this helps. 🙂

Thanks,
Anwesha

Danut M _StonikByte_

Hi @paul,

An easy way to find this information for a specific epic is to check the History tab of that epic. It shows all changes made to the issue, including status transitions and when they occurred.

However, if you need this information for reporting purposes across multiple epics, I would recommend looking for an app (plugin) in the Atlassian Marketplace that provides reporting based on status transitions.

If you want to try such plugin, our Great Gadgets app offers some gadgets that allows you to easily display this information on your Jira dashboards. For this specific case I would recommend one of these gadgets:

Control Chart gadget - can display the time between workflow transitions, like from In progress to Done for the epics returned by a filter/JQL. Hovering an epic in the chart will display the time of the status transitions and the cycle time (duration).

On its Data tab you can visualize the details at the epic level. The report can be exported in CSV format.

Time in Status gadget - can display the total time or average time in each status or status category for your epics.

On its Data tab you can visualize the details at the epic level.

Hope this helps.

Danut.

Rustem Shiriiazdanov _Actonic_

Hi Paul,

Thanks for your question!

Do you need the Epic end dates in Jira, or you want to export them into Azure? Because depending on that you'll need to choose a way of getting dates of Epics.

In general the options are:

Look at one epic by hand. Open the epic and go to the History tab (in newer Jira UI it's under the activity/"History" section of the issue). Every status change is listed there with an exact date and time and the from/to status. For a single epic this is the fastest answer — you'll literally see the line where it went "Ready → In Progress" with the timestamp, and the line "In Progress → Done." Subtract the two and you have your in-progress duration.

Find epics with JQL (good for "which epics did X," not for durations). JQL can filter on transitions but won't give you a column of timestamps. Useful queries:

issuetype = Epic AND status CHANGED FROM "Ready" TO "In Progress"
issuetype = Epic AND status CHANGED TO "In Progress" DURING (2025/01/01, 2025/12/31)<br>
issuetype = Epic AND status WAS "In Progress"

Note JQL only tells you that a transition happened, not when in a reportable way, so it's a finder, not a stopwatch. Also, I am not sure how "During" works in details in Jira 10, you may need to use "" for dates for instance.

Use the REST API / the script (this is what gets you "how long was it in progress"). All of this data lives in the changelog, which you can pull with GET /rest/api/2/issue/EPIC-123?expand=changelog.
The prelimiar look of a script (totally vibe-coded, actually, but when i look into it, it looks good, so you may start with it) is below:

#!/usr/bin/env python3
"""
Report status-transition timestamps and time-in-status for a Jira epic.

Tested against the Jira Software Data Center / Server REST API v2 (works on 10.3.x).
It reads the issue changelog (the "History"), finds every status change with its
timestamp, and:
* prints when the epic entered / left each status,
* highlights the transitions you asked about (Ready -> In Progress,
In Progress -> Done), including repeats if the epic bounced back, and
* sums the *total* calendar time spent in each status (so multiple visits to
"In Progress" are added together).

Usage:
1) pip install requests
2) Fill in the CONFIG block below.
3) python jira_epic_status_times.py
"""

from datetime import datetime, timedelta, timezone

# ----------------------------- CONFIG --------------------------------------
JIRA_BASE_URL = "https://your-jira.example.com" # your Jira base URL, NO trailing slash
PERSONAL_ACCESS_TOKEN = "PUT_YOUR_PAT_HERE" # Jira profile > Personal Access Tokens
EPIC_KEY = "EPIC-123" # the epic you want to measure

# Status names must match EXACTLY what is configured in your workflow,
# including capitalization (check the workflow / History tab if unsure).
STATUS_READY = "Ready"
STATUS_IN_PROGRESS = "In Progress"
STATUS_DONE = "Done"

# Set to False only if your Jira uses a self-signed/internal certificate AND you
# understand the security trade-off. Leaving it True is strongly preferred.
VERIFY_TLS = True
# ---------------------------------------------------------------------------

# Jira returns timestamps like 2025-03-01T10:15:30.000+0000
_JIRA_DATETIME = "%Y-%m-%dT%H:%M:%S.%f%z"


def fetch_issue_status_data(base_url, token, issue_key):
"""Return (created_datetime, changes) where changes is a list of
(timestamp, from_status, to_status) for every status change, oldest first."""
import requests # imported here so the pure functions below stay testable offline

url = f"{base_url}/rest/api/2/issue/{issue_key}"
headers = {"Authorization": f"Bearer {token}", "Accept": "application/json"}
# expand=changelog returns the full history in one call on Data Center/Server.
resp = requests.get(
url,
headers=headers,
params={"expand": "changelog", "fields": "created,summary,status"},
verify=VERIFY_TLS,
timeout=30,
)
resp.raise_for_status()
data = resp.json()

created_dt = datetime.strptime(data["fields"]["created"], _JIRA_DATETIME)

changes = []
for history in data["changelog"]["histories"]:
ts = datetime.strptime(history["created"], _JIRA_DATETIME)
for item in history["items"]:
if item["field"] == "status":
changes.append((ts, item["fromString"], item["toString"]))
changes.sort(key=lambda c: c[0])
return created_dt, changes, data["fields"].get("summary", "")


def compute_time_in_status(created_dt, changes, now=None):
"""Sum total calendar time spent in each status, counting multiple visits.

The epic is in `changes[0].from_status` from creation until the first change;
between two changes it is in the earlier change's `to_status`; after the last
change it remains in that status until `now`."""
now = now or datetime.now(timezone.utc)
durations = {}

current_status = changes[0][1] if changes else None
cursor = created_dt
for ts, from_status, to_status in changes:
durations[from_status] = durations.get(from_status, timedelta()) + (ts - cursor)
cursor = ts
current_status = to_status

if current_status is not None:
durations[current_status] = durations.get(current_status, timedelta()) + (now - cursor)
return durations, current_status


def find_transitions(changes, from_status, to_status):
"""Return timestamps of every from_status -> to_status transition."""
return [ts for ts, f, t in changes if f == from_status and t == to_status]


def format_td(td):
total = int(td.total_seconds())
sign = "-" if total < 0 else ""
total = abs(total)
days, rem = divmod(total, 86400)
hours, rem = divmod(rem, 3600)
minutes = rem // 60
parts = []
if days:
parts.append(f"{days}d")
if hours:
parts.append(f"{hours}h")
if minutes or not parts:
parts.append(f"{minutes}m")
return sign + " ".join(parts)


def fmt_dt(dt):
return dt.strftime("%Y-%m-%d %H:%M:%S %z")


def main():
created_dt, changes, summary = fetch_issue_status_data(
JIRA_BASE_URL, PERSONAL_ACCESS_TOKEN, EPIC_KEY
)

print(f"Epic {EPIC_KEY}: {summary}")
print(f"Created: {fmt_dt(created_dt)}")
print("-" * 60)

if not changes:
print("No status changes found in the history.")
return

print("Status change history:")
for ts, from_status, to_status in changes:
print(f" {fmt_dt(ts)} {from_status} -> {to_status}")
print("-" * 60)

ready_to_ip = find_transitions(changes, STATUS_READY, STATUS_IN_PROGRESS)
ip_to_done = find_transitions(changes, STATUS_IN_PROGRESS, STATUS_DONE)

print(f"{STATUS_READY} -> {STATUS_IN_PROGRESS}:")
print(" " + (" | ".join(fmt_dt(t) for t in ready_to_ip) if ready_to_ip else "(never)"))
print(f"{STATUS_IN_PROGRESS} -> {STATUS_DONE}:")
print(" " + (" | ".join(fmt_dt(t) for t in ip_to_done) if ip_to_done else "(never)"))
print("-" * 60)

durations, current_status = compute_time_in_status(created_dt, changes)
print("Total (calendar) time in each status:")
for status, td in sorted(durations.items(), key=lambda kv: kv[1], reverse=True):
marker = " (current)" if status == current_status else ""
print(f" {status:<20} {format_td(td)}{marker}")
print("-" * 60)

ip_total = durations.get(STATUS_IN_PROGRESS, timedelta())
print(f">>> Total time '{STATUS_IN_PROGRESS}': {format_td(ip_total)}")


if __name__ == "__main__":
main()

Use a Marketplace app if you want recurring, no-code reports across many epics. The app my team developing (Report Builder for Jira https://marketplace.atlassian.com/apps/1216997/report-builder-custom-charts-time-in-status-for-jira ) compute time-per-status with averages, charts, and CSV/Excel export, and run on Data Center. Our and many other paid of free third-party add-ons may save you maintaining a script.

Two things worth flagging for the "how long in progress" number specifically. First, an epic can enter "In Progress" more than once (In Progress → Ready → In Progress is common), so a naive "first entry to first exit" undercounts — the script sums every stint, which is usually what you actually want. Second, all of the above measures calendar time (wall-clock, including nights and weekends). If you need business-hours-only (e.g. excluding weekends), that's extra logic, and it's the main reason teams reach for one of the Marketplace apps.

Natalia_Kovalchuk_SaaSJet_

Hi @paul !

You can find some of this information through Jira's built-in reports and work item history. However, Jira doesn't offer an easy way to report when an epic enters a specific status, when it leaves that status, or how long it remains in each status across multiple epics.

For a single epic, you can check the History tab and manually see when the status changed, for example, from Ready to In Progress and from In Progress to Done. However, this gets tricky when you need to review many epics or generate reports.

If you're open to using third-party apps, you may want to try Issue History for Jira (Work Item History) app by SaaSJet.

With the app, you can:

- Track all status changes for epics and other work items
- See the exact timestamp when a status changed
- Check how long an epic remained in each status
- Export historical data to Excel or CSV, or use the API and export that data in your analytics tools

For your use case, the Advanced Excel reports available in the app can be especially helpful:

Field changes duration report - provides a detailed analysis of the duration between status changes.
Time in field values report - shows how long an epic spent in each status.

Hope it will be helpful for you!

Paul Glantschnig _Appfire_

Hello @paul,

The approaches already shared get you there: the History tab is the quickest way to read the Ready → In Progress and In Progress → Done timestamps for a single epic, and the automation rule with two Date/Time fields is a solid way to capture them going forward.

If you want those timestamps and durations across many epics at once, without building custom fields or maintaining a script, an app from the Atlassian Marketplace can help. JXL for Jira is a spreadsheet/table view for Jira that adds history columns Jira doesn't offer natively:

Time in [status]: cumulative time each epic spent In Progress, summed even if it bounced back into the status more than once.
Time between [status] and [status]: elapsed time from, say, Ready to Done.
Last transition to [status]: the exact timestamp an epic entered a given status.

Add these as columns and they populate for every epic in the sheet, so you can sort, filter, group, and even apply conditional formatting (for example, highlight epics that sat In Progress too long). JXL runs on Data Center, so it fits your v10.3 instance.

Time in status smart column in JXL

Disclosure: I work on the team that builds JXL.

Best regards, Paul

Rahul_RVS

Hi @paul

For detailed reporting for transition changes and time in status for your issues, if you would like to try out a mktplace app, pls explore

Time in Status Reports

With this app you generate time in each workflow status for multiple issues with multiple filter and grouping options. It works for current issues and closed ones as well.

The report below shows the transition changes dates and time stamps.

The app can be easily added as a dashboard gadget and can be shared with colleagues.

More details here.

Disclaimer : I am part of the app team for this add-on

TIS - Status Transition Dates.PNG

Birkan Yildiz _OBSS_

Hey @paul

Welcome to the Community,

While native Jira captures all these changes in the issue history, extracting a clean report with exact timestamps and durations is natively difficult without manually parsing the changelog or using complex REST APIs.
If you are open to using a Marketplace app, you can easily get this exact data using Timepiece - Time in Status for Jira, which is fully compatible with your Jira Data Center environment.

Here is how you can set it up to get both the timestamps and the total duration:
For the Start and End Timestamps: You can use Timepiece's Date Reports.

Specifically, the First Transition To Status Date report will show you the exact date and time the Epic moved to "In Progress," and the First Transition From Status Date will give you the exact timestamp for when it left that status.

For the "In Progress" Duration: You can use the Status Duration report . This report automatically calculates and displays exactly how long each Epic spent in the "In Progress" status.

Pro tip: You can also apply Timepiece's Custom Calendars to your reports to automatically exclude weekends, nights, and public holiday. This ensures the "In Progress" duration you are tracking reflects your team's actual business hours, rather than raw 24/7 calendar time.

You can find Timepiece - Time in Status for Jira on the Atlassian Marketplace.

Full disclosure, I'm on the team that develops Timepiece. Hope this helps.

Vahtang Manukyan - Be On Time

Hi @paul

The suggestions above from @Anwesha and the others are the right way to get the raw timestamps. If you just need a historical audit, the automation rule approach is a solid workaround.

However, from a project governance perspective, I've found that tracking 'In Progress' time is often a symptom of a deeper need: the need for predictability.

The challenge with tracking status-change timestamps is that they are 'lagging indicators'—they tell you how long it took, but they don't help you forecast if the current Epic is going to slip.

If you're trying to move from 'reporting what happened' to 'predicting when it will be done,' I'd suggest looking into Baseline Variance. Instead of just tracking the duration in a status, you compare your actual progress against a planned baseline. This allows you to see the 'drift' in real-time, rather than waiting for the Epic to hit 'Done' to realize it took too long.

Depending on the scale of your portfolios, you might find that moving toward a deterministic scheduling approach (like the Critical Path Method) gives you more confidence than just auditing status timestamps.

Hope this helps you get the visibility you need!

Cheers, Constantin

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

epic

status

time