FastHistory documentation

Where to find FastHistory

FastHistory adds three surfaces, and none of them needs configuration. There is no admin setup and no screen to edit — install it and they are there.

The project page. Open a project and look in its tab bar for FastHistory. If the bar is full, it will be under More. This is the full report.
The issue panel. Open any issue and expand Change history in the right-hand column.
The dashboard gadget. Edit a dashboard, choose Add gadget, and pick FastHistory.

Running a report

The project page opens on the current project straight away — there is no selection step before you see data. To ask a different question, use Scope:

This project — every issue in the project you are in.
Saved filter — any Jira filter you can see.
Choose issues — build a scope from projects, labels, statuses and issue types without writing JQL.
JQL — your own query, for anything the builder cannot say.

Pick one and choose Run report. FastHistory reads the change history for the matching issues in batches and fills the grid as it goes, so a large scope starts showing rows before it has finished.

Reading a row

Every row is one change to one field, not one issue and not one edit. An edit that changed three fields is three rows, because that is what an audit needs to be able to filter.

Column	What it holds
Issue	The issue key and its summary. Click the key to open it in Jira.
When	The timestamp Jira recorded. Repeated timestamps are shown once, on the first row of the group.
Changed by	The person. Where the account no longer exists, or the change was made by Jira itself, the row says so rather than inventing a name.
Field	The field name, with its kind on a second line where that adds something — Assignee · Assignment, Story Points · Custom field. For fields whose kind is just the field name again, the second line is omitted.
Change	The old value struck through, an arrow, then the new one. Empty values are named (unassigned, none, not set) rather than left blank.

Filters and presets

The filter row narrows what is already on screen, instantly — it does not re-query Jira, so it is as fast on ten thousand rows as on ten.

Type — status changes, assignments, estimates, due dates, custom fields and so on.
Field — one or more specific fields.
Person — one or more people.
Date — a range.
Search — across the values themselves, so you can find the change that set a particular value.

The Views menu carries presets for the common questions — status changes, due-date moves, assignment changes, last 7 days, last 30 days.

When a filter leaves nothing on screen, FastHistory names the filter responsible and what removing it would bring back, rather than showing an empty table and leaving you to guess.

Rank and sprint churn

Dragging an issue up a board writes a change to the Rank field. On an active board that is most of the changelog and none of the answer, so rank and sprint churn is hidden by default.

To see it, open the … menu above the grid and choose Show rank & sprint noise. Nothing is discarded — the rows are there, and every count tells you whether it is counting them.

Bulk edits

Relabel 200 issues and a flat changelog gives you 200 rows that push everything else off the screen. The finding — one person touched 200 issues in a minute — is invisible because the evidence is so voluminous.

Open the … menu and choose Collapse bulk edits. A person’s burst of near-simultaneous changes becomes a single row reading, for example, Sam Patel made 24 changes to Labels across 24 issues. Click it to expand the whole burst in place.

A burst needs at least five issues changed within a minute of each other by the same person. The summary strip tells you how many bursts were collapsed.

Grouping, sorting and the Activity view

Group by issue, person or field. The column the grouping already states drops out of the table, because repeating it on every row spends width on nothing.

Every column header sorts. Table and Activity switch between the dense grid and a reading view that groups by day.

The summary strip

Above the grid: the number of changes, issues, people and fields, and the busiest day or month. Show breakdown opens a chart of changes over time, the most-changed fields and the most active people, each with its share of the total.

This is usually where an investigation starts — a spike is visible before you have guessed at a filter.

Saved reports

A scope and a set of filters you will want again is worth saving. Views → Save current view… names it; it then appears in the same menu for everyone who can see the project.

Pin makes a report the project’s default, so the page opens on it. Project administrators only.
Delete removes it. Deleting always works, including when the licence has lapsed — your saved configuration is yours to remove.

Exporting

All three exports contain exactly what is on screen, filters applied, and are generated in your browser rather than on a server.

CSV — for the spreadsheet. Guarded against formula injection, so a value beginning with = cannot execute when the file is opened.
PDF — the artefact you attach to a review. It carries the scope, the filters in force, whether churn was hidden, and a footer stating the report is read-only and no issues were modified.
Summary as image — the summary strip as a PNG for a slide.

If the report was capped, the cap is stated inside the export as well as on screen. An export never quietly contains less than it claims.

The issue panel

The same grid scoped to one issue, in the issue view’s own column: changes grouped by day, each showing the field, the values and who made the change. It has its own field filter and its own export.

The dashboard gadget

A recent-changes feed for any JQL scope — the view a dashboard wants and the project page cannot give, because the project page is bound to one project.

Configure it with a JQL query, a window (up to 90 days), how many changes to show, and a refresh interval. On a shared dashboard the gadget runs as whoever is looking at it, so each person sees only the changes they could already find in Jira’s own search.

Caps, and how they are reported

A report has two limits, and FastHistory tells you when either one binds.

How many issues one report covers. If the scope matches more, the most recently changed are included and the report says so.
How much history it reads per batch. Jira’s changelog API pages from the oldest change forward, so a very deep history can exhaust the budget before reaching the present.

Either way you get a banner naming what was cut and what to do about it, and the same statement travels into the PDF. FastHistory will tell you it does not know something; it will not tell you nothing changed when it simply did not read that far.

What FastHistory cannot see

Comment and worklog text. Jira’s changelog records that a comment changed, not what it said.
Anything Jira did not record. If a change predates a field being tracked, it is not in the changelog and cannot be in a report.
Issues you cannot see. A report runs with your permissions, so two people can legitimately get different totals from the same saved report.
Old values are as Jira stored them. A deleted user or renamed field appears as the string captured at the time — the honest record, rather than a lookup that would quietly rewrite history.

FastHistory also cannot change anything. It holds no write permissions at all, which is enforced by a test that fails the build if one is ever added.

Permissions & your data

FastHistory asks for two permissions: read access to Jira work, and its own app storage. There is no write permission and no egress — the app runs entirely on Atlassian Forge inside your own tenant, and we operate no servers.

No change history is ever stored. Every report is recomputed from Jira’s own record each time it runs. What the app stores is your saved report configurations: a name, a scope, filters, grouping and the time it was saved.

Where a saved report filters by person, that filter holds the Atlassian account IDs it selects, because that is how it re-applies when the report runs again. The report name, the search term and any JQL are stored exactly as you typed them. Deleting the report removes all of it. The full statement is on our privacy policy and in our CAIQ-Lite assessment.

If the licence lapses

Trials, paid subscriptions and the free tier for small sites all have full access. If a trial expires unconverted or a subscription lapses, FastHistory keeps working in a limited form rather than going dark:

You keep the last 7 days of change history for the project you are in, with sorting, grouping, the row count, the Table and Activity views, and bulk-edit collapsing.
Search, filters, the scope picker, exports and running or saving reports need an active licence.
Deleting a saved report always works, licensed or not.

Nothing is deleted when a licence lapses, and everything returns the moment it is active again.

Troubleshooting

I can’t find FastHistory on my project

Look under More in the project’s tab bar — Jira moves tabs there when the bar is full. If it is not there at all, the app may not be installed on your site; a Jira administrator can check under Settings → Apps → Marketplace apps.

The report is empty, but I know things changed

Three common causes. The default view hides rank and sprint churn, so a week of pure board-dragging looks empty — turn it on from the … menu. A filter may be excluding everything, in which case the empty state names it. Or the report was capped before reaching the period you care about, which it will say explicitly.

Someone else sees different numbers

That is the permission model working. Reports run with the viewer’s own permissions, so a colleague who cannot browse one of the projects in scope will see fewer rows. It is not a bug and it is not a caching problem.

A change shows “Unknown user”

The account that made the change no longer exists, or the change was made by Jira itself or by an app. The change is still real and still counted — FastHistory keeps the row and says plainly that it cannot name the actor.

The PDF is several pages and I only wanted the summary

Use Summary as image instead. The PDF is the full row-by-row record on purpose, because that is what gets attached to a review.

“This needs an active FastHistory licence”

The subscription has lapsed or a trial ended. See if the licence lapses for exactly what still works. A Jira site administrator can restore access under Settings → Apps → Marketplace apps.

Something else

Contact support — include the project, the scope you used and roughly when the change you expected happened.