JQL WAS and CHANGED: Search Jira History, Tested

The retro question is “how much did we finish in October, and how much came back?”. The Jira board only knows where things are now. The answer lives in each work item’s history, and JQL can read it with two operators: WAS for “did it ever hold this value” and CHANGED for “did it move”.

We ran every query on this page on our Jira Cloud test site on 13 November 2026, against 162 work items with a few weeks of real history behind them, and counted what each returned.

WAS and CHANGED in one minute

Both take the same time and people filters, called predicates:

DURING takes exactly two dates. status WAS "In Progress" DURING (-7d) fails with The DURING predicate must be supplied with exactly 2 date values. Write DURING (-7d, now()), which Jira accepts.

Now versus ever

WAS includes the present. Atlassian: it finds work items “that currently have or previously had the specified value”. On our site:

The status bars make sense: 29 work items have been in progress at some point, 17 still are. The status a work item was created with counts too: all 48 work items in To Do matched status WAS "To Do", and only 9 of them had ever changed status.

The empty value does not work the same way. 56 work items had no assignee, yet assignee WAS EMPTY found exactly one: the only one whose assignee had been removed. The other 55 were created without one, and nothing in their history says “empty”. For the present, use assignee is EMPTY; for “was unassigned at some point”, JQL has no reliable answer.

The questions, with the queries

What did we finish last month?

status CHANGED TO Done DURING (startOfMonth(-1), endOfMonth(-1))

CHANGED TO Done counts moves into Done, so a work item reopened and closed again counts once in the result (JQL returns work items, not events). For this month so far, status CHANGED TO Done DURING (startOfMonth(), now()) found 22 on our site; since the start of the week, status CHANGED TO Done AFTER startOfWeek() found 15.

Last month, October, that query found 5 on our site. If your workflow has several done statuses, list them: status CHANGED TO (Done, Released) returned the same 27 as (status CHANGED TO Done OR status CHANGED TO Released). Or count resolutions instead: resolution CHANGED found 31 for us.

What was reopened?

Add AFTER -30d for a monthly quality number, and project = PAY to keep it to one team.

What skipped a step?

statusCategory = Done AND status WAS NOT "In Progress" found 25 of our 31 done work items: they were closed without ever being in progress. With review added, status WAS NOT IN ("In Progress", "In Review") AND statusCategory = Done found 24. On a real team this is the list for a “why did these skip review?” conversation, or proof that the board’s columns no longer match how people work.

What was in progress on a given day?

ON with a date is the closest JQL gets to “what was on the board last Tuesday”.

What started this sprint?

status CHANGED FROM "To Do" TO "In Progress" found 15; status CHANGED TO "In Progress" AFTER -14d found 14. Pair it with sprint in openSprints() to keep it to the running sprint.

Who moved what?

BY takes a person: currentUser() or an account ID, or several in brackets.

Six fields, and the error for the rest

Atlassian’s operators page: WAS “can be used with the Assignee, Fix Version, Priority, Reporter, Resolution, and Status fields only”. Everything else fails. On our site sprint CHANGED, labels CHANGED, duedate CHANGED, summary CHANGED and statusCategory CHANGED all returned:

History searches do not support the 'sprint' field.

(with the field’s name). In the REST search API, which apps and scripts use, the same queries came back as Processing of your search request has failed. Enable validation to ensure that your request is correct. That is the message to recognise when an app reports a broken saved filter.

So there is no JQL for “moved between sprints”, “due date was pushed” or “status category changed”. Sprint history needs the sprint report or an app; due-date changes need the work item’s history tab or an export.

Three ways history search goes quietly wrong

1. Typos return nothing. status = "In Progres" fails with The value 'In Progres' does not exist for the field 'status'. status WAS "In Progres" passes Jira’s check and returns 0: old values are not checked, because a status may have existed once.
2. Renamed statuses. Atlassian notes that WAS “will match the value name … which was configured in your system at the time that the field was changed”, and the value’s ID too. If your workflow renamed “In Dev” to “In Progress”, search for both names.
3. Very long histories. For a work item with more than 10,000 changes, WAS only searches the most recent ones (Atlassian’s operators page). Rare, but it happens on automation-heavy items.

Make it a habit

Saved as filters, the queries above become dashboard gadgets: finished this month, reopened this month, closed without review. For the date half of each query, startOfMonth(-1) versus -30d and why -2d is not “since the day before yesterday”, see JQL dates. Paste a history query into the free JQL builder and it warns when a field does not support WAS or CHANGED.

If writing these by hand gets old, our app JQL Blocks has blocks for “created, resolved or changed status during the current sprint, the previous one, or the last N”, and the JQL cheat sheet has every other field and operator.

How we tested

• Site: our Jira Cloud test site on the Standard plan, 162 work items with history from October and November 2026.
• When: 13 November 2026, around 11:00 CET. Relative predicates (-7d, startOfWeek()) depend on the moment you run them.
• How: each query through POST /rest/api/3/jql/parse?validation=strict, then counted with POST /rest/api/3/search/approximate-count.
• Reference: Atlassian’s JQL operators page (WAS, WAS IN, WAS NOT, WAS NOT IN, CHANGED), read the same day.