Cross-project rollups of story points and any numeric field — precomputed, so dashboards open instantly.
The 25-second wall
Every rollup gadget on the Marketplace computes at render time: you open the dashboard, the app fetches thousands of issues, and either you wait — or the gadget dies against Jira’s 25-second invocation limit. Public reviews of the incumbents tell the story: “massive performance issues” on large filters, “sluggish” beyond a couple thousand tickets.
Hierarchy Totals takes the opposite architecture. A background pipeline keeps a snapshot of every watched project inside your Jira (Forge SQL, no external servers), and the gadget render is a single indexed read. A 31,000-issue portfolio rolls up in about a second — and it stays that fast as you grow.
What it does
- True hierarchy rollups — subtask → task → epic → parent, at any depth, with dirty data handled honestly: broken parents, cross-project children, and cycles are surfaced, never silently miscounted.
- Cross-project — pick up to ten projects; each gets its own summary row with correct aggregates, including median (computed from the full distribution, not from sub-totals).
- Six operations — sum, average, median, min, max, count.
- Open work only — one toggle turns every number into remaining work, based on status category, the one thing Jira never lets teams customize.
- Trends — daily history of every aggregate, captured in the background. See how the total moved across the sprint, the quarter, the year.
- Drill-down — every number explains itself: issue keys link into Jira, and the “unestimated” badge opens the exact issues behind it.
Built to be trusted
No data ever leaves your Jira instance. The app has read-only scopes, keeps its snapshot in Atlassian-hosted storage, and shows a freshness stamp on every render — so you always know exactly what you are looking at.
[ frequently asked ]
▸Does my data ever leave Jira?
No. The app runs entirely on Atlassian’s Forge platform: the snapshot lives in Atlassian-hosted storage attached to your installation, the app has no external servers, and its scopes are read-only. Nothing is sent anywhere.
▸How fresh are the numbers?
An hourly background sync picks up changed issues, and any dashboard that is actually being viewed refreshes itself when its data is older than an hour. A daily full re-sync catches deletions and cross-project moves. The footer of every gadget shows the exact “data as of” timestamp — the app never pretends.
▸Will it handle our large instance?
That is the reason the app exists. Rollups are precomputed in the background, so render time barely depends on portfolio size — measured at about a second for 31,000 issues. Trees render in pages of 100 rows per level, so even fully expanded views stay responsive.
▸Which fields can I roll up?
Any numeric custom field — story points, story point estimates, business value, custom effort fields. Pick the field per gadget; different gadgets can watch different fields of the same projects.
▸What operations are supported?
Sum, average, median, min, max, and count. Median is computed from the full distribution of values in each subtree — not from sub-totals — so it is statistically honest at every level, including per-project summary rows.
▸Can viewers see projects they don't have access to?
No. Every read is checked against the viewer’s own Browse Projects permission. A shared dashboard shows each person only the projects they can already see in Jira, with an honest note about how many are hidden.
▸What does the "unest." badge mean?
The number of issues in that subtree with no value in the selected field — counted over leaf issues only, since parent containers conventionally carry no estimate in Jira. Click the badge to see exactly those issues.
▸How does "Open work only" decide what's closed?
By status category — the green/blue/gray classification every Jira status must belong to and no admin can customize. It is the same signal your boards and statusCategory JQL use, so “closed” means the same thing here as everywhere else in your Jira.
▸Why does the gadget ask me to allow access?
Because the app reads Jira on your behalf to enforce your permissions, and Atlassian requires an explicit per-user grant for that. It is a one-time click per user (repeated only after permission-related app updates), and the scopes are read-only.