Limits and sizing

Hierarchy Totals renders from a stored copy of your projects, so most of what a large site changes is how long the first background pass takes and how much detail one render sends to the browser. Render time is driven mainly by how many issues the gadget covers: a 31,000-issue portfolio renders in about a second and a half, 13 projects with 47,000 issues in under three seconds. Totals are computed over the whole hierarchy on the server; when a tree is too large to ship at once, rows load on demand (one exception is listed under Rendering). History does not grow with issue count — it is aggregates only, one compact record per project — or per filtered gadget — per field and day.

The tables below list every number you can run into. Where a limit changes what you see, the tile says so on screen; When a limit is reached at the end lists how.

Configuration

Setting	Limit	What you see
Projects per gadget	50	The settings screen shows (maximum 50) and disables the remaining checkboxes.
Projects in the picker	2,500 listed	A site with more projects gets a search box above the list.
Many projects in one tile	A note past roughly 8	Not a limit — the settings screen points out that one summary row and one trend line per project gets crowded, and suggests a JQL filter for a slice across many projects.
JQL filter	500 characters	The settings screen counts the characters and will not save a longer filter. A trailing ORDER BY is ignored — rows follow the hierarchy.
Fields	Number-type custom fields — Story point estimate, Story Points, business value, your own number fields — plus three time-tracking fields: Original estimate, Time spent and Remaining estimate, shown in hours	Other field types are not offered in the picker.
Operations	sum, avg, min, max, median, count	—

Rendering

What	Limit	What you see
Issues read per render	50,000	Above that how it’s counted in the footer says partial: above the size cap and names the projects with no data (up to four, then +N more) and the project it cut through as only partly summed; the what’s counted panel says the same. Narrow the projects or the filter for complete numbers.
Rows sent to the browser	No fixed number — on a very large tree the deepest rows are held back and load on demand	Totals are computed over the whole tree, but on a very large one the deepest rows are held back. A row whose children were held back shows a +N … chip; clicking it loads exactly that branch. How it’s counted counts them: N rows not listed (totals include them). The exception is a project with no hierarchy at all — thousands of issues on one flat level: the rows past what one render can send are left out, and how it’s counted says N issues in rows that did not fit — NOT counted in the totals above. See Drill-down.
Rows per level	100	A Show 100 more (N hidden) row pages through the rest of that level.
The DONE column	Shown on tiles wider than 520 px	On a narrower tile the column is hidden; the Σ column and the unest. badges stay.
Right-hand column (unest. badges and +N … chips)	Shown on tiles at least 300 px wide	Below that the column is dropped; a row with children held back shows a +N chip next to its key instead.
Numbers	Up to two decimal places, in your Jira locale	Time-tracking fields are shown in hours with an h suffix.
DONE %	Exact 0 % and 100 % only at the ends	Anything in between is shown within 1–99 %, so a row with one open work item among hundreds never reads as 100 %. The share counts work items — issues with nothing below them — so an open epic whose work is all done does read 100 %.
Issue summaries	First 120 characters	Longer summaries are cut in the row; the issue key opens the issue in Jira.
View state	12 hours	Expanded rows, unestimated-only mode, the open Trend panel and the scroll position are remembered in your browser per gadget for 12 hours, and forgotten when the gadget settings change.

Background sync

What	Value	What you see
Full re-read	Once a day, every configured project, hour chosen by the platform	This is the pass that removes deleted issues and issues moved to another project.
Hourly update	Once an hour, plus whenever someone opens a dashboard whose data is more than an hour old	Changed issues are written into the stored copy in place.
First pass	Starts on the first render of a new project or field; minutes on a small site, an hour or more on a large one	Until it lands the tile shows a live preview of up to about 500 issues with live preview in the footer, and replaces it with the complete numbers on its own; they may be higher or lower.
First pass pacing	Seven projects at a time, fourteen minutes apart	With 50 projects the last group starts about an hour and forty minutes after the first. A project waiting its turn reads starting… or never synced on the admin page.
Live preview re-reads	Every 90 seconds, less often when Jira’s hourly request budget for the app is low; stops after five failed refreshes in a row	Each failed refresh doubles the wait, up to 15 minutes. After the fifth the footer says stopped refreshing; reload the dashboard; one refresh that succeeds resets the count.
Staleness warning	48 hours	The tile says These numbers are N days old above the table and keeps showing them with their date; a second notice appears when hourly updates land but no full re-read has completed in 48 hours. On the admin page a project’s Last complete turns amber at the same threshold.
Idle projects	30 days without a render	The project stops syncing and its stored copy is dropped; its trend history is kept. The next view registers it again and starts a fresh first pass, with a live preview meanwhile.
Manual re-sync	One per project per 10 minutes	The re-sync link on the admin page needs project-admin rights on that project; a second request inside 10 minutes is refused with the reason shown, and so is any request on a site whose subscription is inactive.
Deleted projects	Dropped from the sync after 14 days of not being found in Jira	Reported as not reachable in the tile meanwhile. A project in the trash is kept indefinitely in case it comes back.

Details of each pass and of the admin page are on Freshness & performance.

Trends

What	Value	What you see
History points	One per project, per field, per day, stored when the full re-read finishes	The first point lands with the first full pass.
First line	From the second day	Until then the Trend panel shows the first value and says the line starts with tomorrow’s sync. A filtered gadget’s series starts the day the filter is configured; editing the filter starts a new series.
Retention	Daily points for 90 days, then weekly to two years, then monthly	Older points are thinned to one per week and then one per month; the series itself is kept.
Range drawn	Up to 400 days back	There is no range selector; the chart shows everything stored in that window.
Filtered or multi-project series	50 per site, captured daily, most recently viewed first	A gadget beyond the budget is skipped that day and says so in its Trend panel; viewing it moves it back into the budget. Per-project history is not counted against this.
Issues per filtered or multi-project capture	400,000	Above that the daily capture skips the point and the Trend panel says so; narrow the projects or the filter to restore it.

How each series is counted, and which lines are withheld from a viewer who cannot see the whole scope, is on Trends & history.

Hierarchy Progress

What	Limit	What you see
Columns by tile width	All columns at 720 px and wider; DONE, the main share and the bar from 521 to 719 px; the main share and the bar at 520 px and below	The main share is % by weight, or % done when the gadget counts issues only. Below 720 px the unest. badge has no column, so a * after the share marks a row with unestimated work.
Parent issues behind a DONE link	200	The link lists the row’s whole subtree by naming the row and every issue under it that has children of its own. Up to 200 of those it opens the whole subtree; past that it opens the row’s direct children, and its tooltip says so.
% done and % by weight	Exact 0% and 100% only at the ends	Anything in between is shown within 1–99%.
Trend lines	One per project, or one for a filtered gadget	No line per epic or per initiative. The line starts when the gadget is set up.

The counting rules are on Hierarchy Progress.

Filters

What	Limit	What you see
Matches per query	50,000 issues	How it’s counted says partial: above the size cap and the what’s counted panel asks you to narrow the projects or the filter. The trend capture of such a filter is skipped with a message in the Trend panel.
Saved-filter references	5 per query (filter = …)	A query with more is treated as unreadable: the first-render preview is not shown and the trend is not captured, and the tile says so.
Saved filters not shared with the app	Must be shared with “Hierarchy Totals” or with everyone	Otherwise the first-render preview cannot run and the trend cannot be captured; once the first background pass has finished the filter runs as the viewer and works regardless.
Filters that depend on who is asking	currentUser(), currentLogin(), lastLogin(), myApproval(), myPending(), myOrganizations(), issueHistory(), votedIssues(), watchedIssues(), projectsWhereUserHasPermission(), projectsWhereUserHasRole(), projectsLeadByUser(), componentsLeadByUser()	They work in the tile, run as the viewer. They are refused for the first-render preview and for trend capture, where there is no viewer to run them as; the tile says so each time.

The reasoning behind each rule is on Filtering with JQL.

Measured performance

Both figures are render times of a precomputed snapshot.

Portfolio	Render time
31,000 issues	About a second and a half
13 projects, 47,000 issues	Under three seconds

Both are reads of a stored copy, so the number of issues a gadget covers — not the number of gadgets or dashboards on the site — is what these figures scale with. Adding projects mainly lengthens the first background pass, which starts them seven at a time, fourteen minutes apart.

When a limit is reached

Nothing is dropped without a word:

The footer itself is one line — freshness, the issue count and three links. What the table does not show is one click away, behind how it’s counted.

• Over the read limit — how it’s counted says partial: above the size cap and names the projects with no data or only partly summed; the what’s counted panel repeats it in its first sentence.
• Over the match limit of a filter — how it’s counted says partial: above the size cap and the what’s counted panel asks you to narrow the projects or the filter; the trend capture of that filter is skipped.
• Rows held back — rows with a parent on screen are always in the totals, and how it’s counted counts them: N rows not listed (totals include them). Top-level rows that did not fit are the one exception: it says N issues in rows that did not fit — NOT counted in the totals above.
• A branch that arrived incomplete — the row carries a partial chip: the stored copy was read up to its size cap, so some rows below are missing, and the numbers on that row cover only what was read.
• A project you cannot see — counted as hidden, never shown; a notice above the table says how many projects are hidden from you and why (N projects are hidden — you don't have access…). See Security & data handling.
• A trend that cannot be drawn — the Trend panel says why: beyond the series budget, a filter that cannot be captured, a daily capture that failed on its last run, or a scope the viewer cannot see in full. A line withheld under issue security is named under the legend.
• A filter that cannot be applied — a filter with an unpaired parenthesis or quote is refused, and the tile shows a filter error rather than unfiltered numbers.
• A setting over its limit — the settings screen refuses to save and says which limit.

If a limit on this page is in your way, or you are sizing a portfolio well beyond the figures above, write to us through the contact form — we answer within two business days.