Skip to main content

How to See Who Changed What in Jira — Field-Level Issue History

· 5 min read
NGPilot

Every Jira issue keeps a diary. Status flips, priority bumps, reassignments, edited specs — Jira writes all of it down. The problem is reading it back: the built-in history turns a description edit into one unhelpful line, and "who changed this?" across forty issues becomes forty clicks or a REST script. This guide covers three ways to actually read Jira issue history, from the free built-in tab to field-level diffs and a cross-issue CSV report.

Quick answer: Jira's History tab shows every change but collapses long-text edits to "Description updated" and only covers one issue at a time. For field-level answers — what exactly changed, across many issues, exportable for audits — install Issue History for Jira: a panel on every issue with word-level diffs, a JQL-driven multi-issue report, CSV export, and a Rovo agent that answers "what changed?" in plain language. Free for up to 10 users.

Method 1 — the Built-in History Tab (Free, Shallow)​

Open any issue, scroll to the History tab. Every change is there: who, when, and old → new values for simple fields like status, assignee, and priority.

Good for: "when did this move to Done?" on a single issue with a short history.

What's missing: long text fields are the blind spot — an edit that deletes three acceptance criteria shows as Description updated, with no before, no after, and no way to diff without leaving Jira. And the view is strictly per issue: there is no search across histories, no filter by field, and no export. The moment the question spans issues ("everything that offboarded admin touched"), the History tab becomes a manual tour.

Method 2 — the REST Changelog API (Complete, Scripted)​

Jira's REST API exposes the full changelog, including values the UI hides:

curl -u email@example.com:API_TOKEN \
  "https://your-site.atlassian.net/rest/api/3/issue/PROJ-42/changelog"

Each entry carries items[] with field, fromString, toString, author, and timestamp — the raw material for a complete answer.

Good for: admins building a one-off audit extraction, or wiring change feeds into other tooling.

What's missing: it is a script you now own — pagination, rate limits, and value formatting included. Every audit request becomes a rerun, and the output still needs a diff view for long text before anyone can read it. Powerful, but nobody wants this as their day-to-day interface.

JQL offers partial help without any scripting: the CHANGED and WAS operators work on a fixed set of fields (status, assignee, priority, fix version, sprint):

status CHANGED AFTER -7d
assignee CHANGED BY "former.admin@company.com"

What's missing: the field list is fixed — no JQL ever answers "whose description changed last month?", and the operators return issues, not the change values themselves.

Method 3 — a History Panel with Diffs, Reports, and a Rovo Agent (Recommended)​

Issue History for Jira turns the changelog into something readable at three scopes:

  1. One issue — a panel lists every field change newest-first: author, time, and exact before → after values, with paging for long histories.
  2. One edit — long text changes get a focused diff with word-level highlighting, so "Description updated" becomes the three words that actually moved.
  3. A whole issue set — the global report runs over any JQL filter, with date and field filters, and exports to a formula-safe CSV that spreadsheets cannot corrupt.

Because the report is JQL-driven, audit-style questions are saved filters rather than projects:

project = FIN AND updated >= -30d      # everything financial that moved this month
assignee CHANGED BY "former.admin@company.com"   # bulk-edit fallout, one table

There is also a fourth door: in Rovo chat, the Issue History agent answers plain-language questions — "what changed recently on this issue?", "who last edited the acceptance criteria?" — from live Jira data, with sources. Every query runs as the asking user, so the agent only ever surfaces history the asker could already read, and the app holds a read-only scope and stores nothing.

Find the Answer, Then Keep It​

The CSV export is where history stops being a curiosity and becomes a record: issue key, field, author, timestamp, old value, new value — one row per change, ready for an audit pack, a change advisory board, or a post-incident review. Filter the report before exporting ("status changes on these 40 issues in the last 30 days") or the evidence becomes homework.

Which Method Should You Use?​

NeedUse
"When did this issue move to Done?"Built-in History tab
A one-off complete extraction for scriptingREST changelog API
Field-level diffs, cross-issue reports, CSV, plain-language answersIssue History for Jira

For the third row — compliance evidence, dispute resolution, release retrospectives, and the everyday "who changed this?" — the setup cost is one install, and it pays back the first time a diff answers a question a changelog line couldn't. Install Issue History for Jira and make the history readable where the work happens.

Related guides