To help you better understand where JQL works best for historical reporting, we’ve compiled the following table, showing which field types are compatible with historical operators.

Field Type

Supports Historical Operators

(WAS, WAS IN, WAS NOT, WAS NOT IN, CHANGED)

Example queries with historical operators and notes
Status Yes with all operators
  1. status was “In Progress”
  2. status was not “Done”
  3. status was in (“To Do”, “In Progress”)
  4. status was not in (“To Do”, “Done”)
  5. status changed BEFORE “2024-06-30”
Priority Yes with all operators
  1. priority was “High”
  2. priority was not “Critical”
  3. priority was in (“High”, “Critical”)
  4. priority was not in (“Low”, “Medium”)
  5. priority changed DURING (startOfDay(-30), endOfDay())
Assignee Yes, but only with WAS, WAS NOT, CHANGED
  1. assignee was “John Doe”
  2. assignee was “John Doe” AND assignee changed
  3. assignee was “Jane Smith” AND assignee is EMPTY
  4. assignee was not “Jane Smith”
  5. assignee changed FROM “John Doe” TO “Jane Smith”
Reporter Yes, but only with WAS, WAS NOT, CHANGED*
  1. reporter was “Jane Smith”
  2. reporter was not “John Doe”
Resolution Yes with all operators
  1. resolution was Fixed
  2. resolution was not Duplicate
  3. resolution was in (“Fixed”, “Won’t Fix”, “Duplicate”)
  4. resolution was not in (“Fixed”, “Won’t Fix”, “Duplicate”)
  5. resolution changed TO “Won’t Fix”
Fix Version Yes with all operators
  1. fixVersion was “1.0.0” AND fixVersion is EMPTY
  2. fixVersion was not “2.0.0”
  3. fixVersion was in (“1.0.0”, “2.0.0”, “3.0.0”)
  4. fixVersion was not in (“Alpha”, “Beta”)
  5. fixVersion changed FROM “1.0.0” TO “2.0.0”
Custom Fields (Date/Time) Depends on configuration** Jira doesn’t automatically track changes to Custom Fields in the audit log or issue history unless specific configurations are made.
Custom Fields (Text) No Only current value is stored for Text fields. **
Attachment No While you can see the list of attachments on an issue, Jira does not maintain a history of when attachments were added or removed.
Component No This field is a static field that is set on the issue level and does not track changes over time.
Comment No The comments are stored with the issue but not in a way that allows historical querying of who commented or when a comment was added.
Due Date No It is treated as a one-time value on the issue that can be changed as needed, and Jira does not retain this historical change data
Epic Link No When you change the Epic Link field, Jira does not track the historical changes to which epic an issue was linked. Once the value is updated, Jira only keeps the current association.
Linked Issue No Jira stores only the current state of the link field.
Issue Type No The Issue Type is set when the issue is created and is rarely changed afterward (and even if it is changed, this change does not get recorded historically.
Labels No When labels are changed, Jira updates the field with the new set of labels but does not keep a historical record of previous labels.
Parent (Sub-task) No This is a single-value field, and once the parent is changed, the old parent relationship is not preserved.
Project No Changing the project of an issue is a relatively rare action, and Jira does not maintain a history of project changes.
Sprint No Once an issue is moved between sprints, Jira does not store the previous sprint assignments.
Time Tracking (Original Estimate, Time Spent) No Time Tracking fields are continuously updated when work is logged or estimates are adjusted. Jira does not maintain historical records of how much time was logged at specific points in time.
Worklog data No Data such as worklog author, worklog date, etc) is stored in Jira’s worklog entries, but worklogs themselves are not quarriable historically in the same way as other fields.