Trends & history — Hierarchy Totals docs

Click Trend in the gadget header and a chart opens above the table: one line per configured project (a filtered gadget draws a single line — see below), a value axis on the right, dated ticks along the bottom, a legend with each project’s latest value, and the exact date range of the history on show.

The Trend panel open above the Hierarchy Totals table: three lines for the projects PLAT, MOBL and DES rising over two months, a legend reading PLAT 65, MOBL 62, DES 41, a value axis on the right ticked 0, 20, 40 and 60, weekly date ticks below running Jul 6, Jul 13, Jul 20, Jul 27, Aug 3, Aug 10, Aug 17, Aug 24 and Aug 31, the date range 2026-07-04 → 2026-09-01, and underneath the table with PLAT 65 at 53 %, MOBL 62 at 43 % and DES 41 at 33 % over the footer data as of 2026-09-02 06:40 UTC · 50 issues · how it's counted · support · debug. — One line per project, weekly ticks along the bottom, round values on the right. The legend carries the latest value of each line — 65, 62 and 41, the same numbers as the bold project rows in the table below it.

What is captured

Once a day, when a project’s full re-read finishes, the background sync stores one history point per configured project and field. Each point holds every aggregate — sum, average, median, min, max, count and the number of unestimated issues — in two variants: all issues, and open work only. Because all of them are stored, changing the aggregate in the gadget settings keeps the history, and the open-only variant shows remaining open work over time, per project. The same point holds the counts and weights that Hierarchy Progress draws its percentages from.

The first point lands with the first full pass, so history begins the day you add a project. A line needs two points, so the chart appears from the second day; until then the Trend panel shows the first value and says the line starts with tomorrow’s sync. History is observed, never reconstructed: nothing is backfilled from Jira’s issue history.

An empty Trend panel says why it is empty. Before the first point it reads History starts today. If the daily capture failed on its last run, it says that instead: the trend has no point for that day, and the capture runs again with the next full re-read. Once a chart exists, the same sentence sits under it with the date of the last captured point, so a capture that stopped is not hidden behind older points.

What the chart draws

One line per project, for the aggregate you configured: a sum gadget draws sums, a median gadget draws medians. A gadget set to Open work only draws the open-only variant, so the lines match the numbers in the table below them. The legend shows each line’s latest value. The ticks along the bottom sit on calendar boundaries — single days for a short history, Mondays for a month or two, month starts for a year — and there are as many of them as the tile is wide enough to label; the value axis on the right uses round numbers.

Move the pointer over the chart to read a single day: a vertical cursor snaps to the nearest captured day, a dot marks each line, and a card shows the date with every project’s value on it. A project with no point that day shows a dash, not a zero. It works with a finger on a touch screen as well.

The same Trend panel with the pointer over 11 August: a vertical cursor line just past Aug 10, a dot on each of the three lines, and a card to the left of the cursor reading 2026-08-11, PLAT 57, MOBL 45, DES 18, while the legend below still shows the latest values PLAT 65, MOBL 62, DES 41. — Hover any day for its exact values — on 11 August PLAT stood at 57 of today's 65. Past the middle of the chart the card flips to the left of the cursor, so it never leaves the chart.

The range is the stored history, up to 400 days back: daily points for the last 90 days, one point per week (plus the first of each month) before that. There is no range selector — the chart shows everything stored in that window, and missing days are never filled in.

Several projects

For a gadget watching several projects, each line is counted the way the table groups: a subtree belongs to the project of its topmost parent, even when children live in other projects, so each line matches its project row.

Two caveats:

Grouped counting starts with the first daily capture after the gadget is first shown. Days before that show each project counted on its own.
A viewer who cannot browse one of the projects sees per-project lines for the projects they can see. Grouped counting is skipped for them, because grouped numbers cannot be re-filtered per viewer without revealing totals from a hidden project.

Issue security

A history point is one number for a whole project, captured in the background. It cannot be re-counted for each viewer, and day-over-day changes would reveal the values of issues a viewer’s issue security hides. So the trend is checked against each viewer, line by line.

A project’s line is withheld from a viewer when that project holds an issue with a security level the viewer’s account is not in. When such an issue belongs to a subtree whose topmost parent is in another selected project, that project’s line is withheld as well, because the whole subtree is counted there.

Every other line is drawn as usual. Under the legend the panel names what is missing — DES’s line is hidden: it holds issues with a security level your account cannot see — and gives no count of those issues.

The whole trend stays hidden only when the check cannot be settled: the security check failed or was cut short, more than 2,000 hidden issues are involved, or the parent chain of a hidden issue cannot be followed to a selected project. The panel then says the trend covers issues hidden from you.

Filtered gadgets

A gadget with a JQL filter gets a single series, labeled Filtered total: the aggregate of exactly the issues the filter matches, across every configured project, captured once a day under that configuration. It starts the day the filter is configured, and editing the filter starts a new series — a changed question gets a new baseline. Filters that depend on who is viewing (currentUser() and friends) cannot be captured in the background, so a gadget using one has no trend.

The viewer rule is stricter here than for per-project lines, because the single series blends every configured project into one number and cannot be split. It is withheld from anyone who cannot browse all of the configured projects.

It is also withheld from any viewer who is outside a security level used in those projects — even when the filter matches none of the restricted issues. The check looks at the projects, not at the filter, so the chart never depends on issues the viewer cannot open. Some viewers lose a chart they could have been shown; no viewer learns anything about a restricted issue. The panel says the trend stays hidden while anything in that scope is not visible to you.

Filtered and multi-project series share one budget: up to 50 per site, captured daily, most recently viewed first. A gadget beyond it says so in its Trend panel. How the budget is spent is on the Filtering with JQL page; per-project history is not counted against it — it is captured for every configured project and field.

Retention

History is aggregates only — one compact record per project, field and day — so it cannot bloat your site. Daily points are kept for 90 days, then one point per week, and one per month after two years. Per-issue data is never stored historically, so the footprint stays effectively constant whether you run the app for one year or ten. A project nobody has viewed for 30 days stops syncing, but its history is kept and capture resumes with the first full pass after the next view. Every number on this page is listed with the others on the limits page.