JQL cheat sheet: 23 Jira queries for history, changes and pull requests
Copy-paste JQL for Jira Cloud: text search, date ranges, status history with WAS and CHANGED, linked work items, sprints, and the development fields that find work with open pull requests or failing builds.
The KnowWhyy team · · 4 min read
JQL (Jira Query Language) is how you get Jira to answer real questions: what changed last week, what was ever in progress, which "done" work still has an open pull request. This cheat sheet collects the queries engineering teams actually reach for, with a focus on history and development data, which are the least documented parts of JQL.
Everything here works in Jira Cloud without apps unless noted, as of November 2026. One terminology note: Jira now calls issues work items, but JQL still uses issue in functions like linkedIssues().
Five rules that save you time
Use account IDs, not usernames. Jira Cloud JQL doesn't accept usernames. Use currentUser(), or pick the person from the autocomplete so Jira inserts their account ID.
text ~ searches several fields at once: summary, description, environment, comments and text custom fields. A trailing * does a prefix match; text !~ isn't supported (text search docs).
WAS and only work on six fields: Assignee, Fix Version, Priority, Reporter, Resolution and Status (). You can't search the history of a description or custom field this way.
Ask your first question in minutes.
Create a workspace, connect a tool and choose what gets indexed. The free plan includes GitHub, Slack and Notion.
Sprint functions only accept IN and NOT IN, as in sprint in openSprints().
Development fields need the GitHub (or Bitbucket, GitLab) integration, and only a handful of forms are documented. See the development section below.
Find work by text and dates
text ~ "payment timeout" AND project = ENG
Work items mentioning both words anywhere in summary, description or comments.
summary ~ "login*" AND statusCategory != Done
Open work whose summary has a word starting with "login".
project = ENG AND updated >= -30d ORDER BY updated DESC
Everything touched in the last 30 days, newest first.
created >= startOfMonth() ORDER BY created DESC
Work created this month.
created >= startOfMonth("-1") AND created < startOfMonth()
Work created last month.
resolution = Unresolved AND priority in (Highest, High) ORDER BY priority DESC, created ASC
The open high-priority backlog, oldest first within each priority.
Search the history: WAS and CHANGED
These are the queries that answer "what happened", not just "what is".
status WAS "In Progress"
Work that is, or ever was, In Progress.
status CHANGED FROM "In Progress" TO "Done" DURING (startOfWeek(), endOfWeek())
Work completed this week, useful for a weekly update.
status WAS "Resolved" BY currentUser() DURING ("2026/01/01", "2026/06/30")
Work you resolved in the first half of 2026. Swap currentUser() for a teammate via autocomplete.
assignee CHANGED AFTER -7d AND project = ENG
Work that changed hands in the last week, a quick signal of churn.
priority CHANGED BY currentUser() AFTER startOfWeek()
Work whose priority you changed this week.
assignee = currentUser() AND resolved >= startOfWeek()
What you resolved this week.
Find related work: links and parents
issue in linkedIssues("ENG-123")
Everything linked to ENG-123. This is built in; you don't need an app for a single work item.
issue in linkedIssues("ENG-123", "blocks")
Only the work ENG-123 blocks.
project = ENG AND issueLinkType in ("blocks", "is blocked by")
Work in a space that has blocking links of either direction.
parent = ENG-42
All children of epic ENG-42. The parent field replaced Epic Link; use the epic's key, not its name.
Needs an app: "everything linked to anything in project X" isn't possible in core JQL. Queries like issueFunction in linkedIssuesOf("project = ABC") need ScriptRunner or a similar Marketplace app.
Sprints
sprint in openSprints() AND assignee = currentUser() AND statusCategory != Done
Your unfinished work in the current sprint.
sprint in closedSprints() AND resolution = Unresolved
Work that spilled over from finished sprints.
sprint in futureSprints() ORDER BY rank
What's planned next, in priority order.
Development data: pull requests, commits and builds
With the GitHub for Atlassian app connected, Jira can search development information. Atlassian documents these forms for Jira Cloud: development[pullrequests].all, development[pullrequests].open, development[commits].all, development[reviews].all, development[reviews].open and development[builds].failing.
development[pullrequests].open > 0 AND statusCategory = Done
Work marked Done that still has open pull requests. Run this before every release.
development[commits].all > 0 AND development[pullrequests].all = 0
Code was committed but no pull request was opened, often a sign of work done outside review. The = 0 form comes from community answers, so test it on your site.
development[builds].failing > 0 AND sprint in openSprints()
Current sprint work with failing builds.
deploymentEnvironmentType ~ "production" AND deploymentState ~ "successful" AND updated >= -7d
Work deployed to production in the last week (via the deployment fields; not available for Bamboo deployments).
Be careful with undocumented forms. Variants like development[pullrequests].merged, development[branches] and development[deployments] circulate online but aren't in Atlassian's documentation and are reported to error on Jira Cloud. Older reports also say development fields don't return work items from team-managed spaces, so test on your own site.
Save the queries your team reuses
Save any of these as a filter, share it with your team, and subscribe to it for a weekly email. "Done with open PRs" and "completed this week" are the two most teams end up keeping.
What JQL can't tell you
JQL is excellent at what and when: which work changed status, who resolved it, which items have open pull requests. It can't tell you why. The reasoning behind a decision is rarely in a Jira field; it's in the PR review, the Slack thread where the trade-off was argued, or the design doc. That's why a good ticket template records the decision and links the discussion, and why it's worth knowing how to recover the reason behind a change when the ticket doesn't say.
Where KnowWhyy fits
KnowWhyy answers the "why" questions JQL can't. It connects GitHub, Slack and Notion, and when you ask "why does the importer skip rows over 10 MB?", it answers from the commits, pull requests, threads and pages involved, with a citation for each claim. KnowWhyy doesn't read Jira yet (it's on the roadmap), but because linked PR titles carry Jira keys, the ticket reference appears right in the sources it cites.
The short version
Use currentUser() or autocomplete for people; Jira Cloud JQL doesn't take usernames.
text ~ searches summary, description and comments at once.
WAS and CHANGED search history, but only for Assignee, Fix Version, Priority, Reporter, Resolution and Status.
issue in linkedIssues("KEY") is built in; project-wide link searches need an app.
Stick to the documented development fields, such as development[pullrequests].open, and test anything else on your own site first.