How to capture the “date of change” for Jira issues

[#1]

Issues or tasks in Jira go through numerous modifications as teams collaborate and priorities shift. Someone might change a status, assignee, priority, or any other field. How do you capture the “date of change” for those updates?

Spoiler: there is no built-in field for this purpose.

So, if you’re wondering how to track and analyze these changes accurately, let’s dive into some workarounds to ensure you have complete visibility over your project’s evolution.

Option 1. History for a single issue + JQL

The History tab is the simplest way to see changes made to a single Jira issue. It provides a chronological log of modifications — status, assignee, priority, and many other fields — all with precise timestamps.

This approach works well if you only need to check a few issues.

However, it quickly becomes inefficient when you need a project-wide view or want to analyze trends. JQL helps, but with limitations: history searches work only for six fields, and you still need to open each issue manually to see the actual date of change.

Example:
You want to know when issues transitioned from To Do to In Progress.

JQL:

project = "Marketing Classic" and status changed FROM "To do" TO "In progress"

Then, you will get the list of issues that reflect that condition. Open each issue and check the history to see the change date for this specific status transition.

This method is time-consuming and can work if you don’t have too many issues to check. So, let’s move to the next option.

Option 2. Jira Automation

A more scalable approach is to use Jira Automation to automatically record change dates in a custom field.

You can configure a rule that triggers whenever an issue transitions or when a specific field changes. The rule writes the timestamp into a custom field such as “Last Status Change.” This field can then be queried via JQL or displayed in issue search results.

Steps:

1. Go to Jira Settings: Navigate to Jira Settings > Issues > Custom Fields.

2. Create a New Custom Field: Click on Create custom field, select Text Field (single line) or Date/Time Picker (depending on your needs), and name it something like “Last Status Change.”

Example of the Automation rule:

1. Trigger: Start with an “Issue Transitioned” (or “Field Value Changed” for other fields) trigger and specify particular statuses.

2. Action: Select the “Edit Issue” action to set the custom field (e.g., “Last Status Change”) to the current date and time. Use the smart value {{now}} to capture the exact moment the change occurs.

 

Now, every time an issue transitions to a specified status, the date and time will automatically populate in the “Last Status Change” field, keeping a clear record of recent changes. You can then use JQL to search based on this field or add it to your issue views for easy tracking.

This option is more effective but not ideal if you want to track the “date of change” for multiple or all issue fields.

Option 3. Issue History for Jira app to track the “date of change” for all fields 

Issue History for Jira app automatically records each update, displaying the history in an easy-to-read and customizable format. If you need complete visibility across all issues, fields, and time periods, the app is the most efficient option.

The “date of change” is displayed in a separate column. You can also filter changes by specific projects, fields, or time periods, making it simple to monitor updates across multiple issues. 

 

Since the app centralizes all historical data, you don't need to create multiple custom fields or automation rules, reducing complexity and ensuring accurate records.

Meaning you can instantly answer questions like:

• When did status change?

• When was the priority updated?

• When did the assignee switch?

• What changed last week in my project?

No custom fields.
No automation rules.
No manual digging.

Just a centralized report with all historical changes.

Get all past updates in one report

Let’s sum it up

Tracking the “date of change” in Jira can be achieved through various methods depending on your needs. 

• History tab. Provides a straightforward view of changes made to a single issue, including dates and timestamps [good for quick insights but limited for broader analysis].

• Jira Automation. Set up automation rules to log the date and time of status changes into a custom field [ideal if you want to track the “date of change” for specific field changes like status or another].

• Issue History for Jira. A comprehensive solution that captures the date and time in a separate column for multiple fields and issues. This app simplifies tracking without manual effort, making it ideal for teams needing detailed change history.

Get a precise timestamp for every status, assignee, priority, or field update — without custom fields or automation.

➡️ Start a free trial of Issue History for Jira and capture every “date of change” automatically.

[Bill Sheboy]

Hi @Yuliia_Borivets__SaaSJet_ 

Thanks for the summary of methods to track the date-of-change for fields, beyond what is provided by the built-in, JQL supported checks. 

And, please consider there could be exceptions for all of these methods, as some field changes do not trigger the issue-updated event and / or do not write to the change history.  Some changes are even written incorrectly to the history for edge cases (e.g., for lots of changes to list fields like Fix Version and Sprint).  There are other examples in the public backlog for the built-in field tracking cases, and some marketplace apps use their own field-change tracking, independent of the issue history.  Experimentation helps to confirm when a field's changes can / cannot be tracked.

Kind regards,
Bill

[Yuliia_Borivets__SaaSJet_]

Hi @Bill Sheboy 

Thank you for your comment and for pointing out these key considerations!

There are indeed exceptions when tracking changes. As you suggest, experimenting is key to understanding when these methods will or won’t capture changes accurately.