One reporting engine for Jira dashboards, with four ready-made presets. It answers the questions the built-in gadgets leave open: what a filter adds up to, how work splits across two fields at once, how far each epic has got, and where the work currently sits. Free for teams of up to 10 users, and nothing leaves Atlassian.
The four presets are entry points into the same engine, not four fixed reports. Each one lets you choose the filter, what to measure, and how to group it — and the list of dimensions is read from your own instance, so it includes your custom fields. Start from whichever preset is closest to the question you are asking.
Adds up a numeric field across everything matching a filter, grouped by one dimension, and shows the result as a total, a bar chart and a sortable table.
| Setting | What it does |
|---|---|
| Which issues | A saved filter, a project, or your own JQL — for example project = ABC AND statusCategory != Done. Saved filters are listed with your favourites first; projects with the most recently used first. |
| What to sum | Any numeric field in your instance — story points, original estimate, a custom cost or effort field. Choose Issue count to count issues instead of summing. |
| Group by | Parent (the epic or issue above), assignee, status, priority, issue type, label or project. |
| How many groups | How many rows the table shows. The chart shows the ten largest. |
The big number is the total across every issue in the filter, counted once each. The table lists each group with its own sum and issue count, largest first. If a message appears above the chart, it is telling you something that would otherwise make the number quietly wrong — see the FAQ.
Splits the same filter across two fields at once and shows a table with row totals, column totals and a grand total. Each cell counts issues, or sums a numeric field.
| Setting | What it does |
|---|---|
| Which issues | A saved filter, a project, or your own JQL. |
| Rows / Columns | The two fields to compare. Both lists are built from your own instance, so they include your custom fields — see below. |
| What to show in each cell | Issue count, or the sum of any numeric field. |
| How many rows / columns | Rows and columns are ordered by size and cut at these limits. The gadget tells you when there were more. |
The table adds up on its own terms: every row total is the sum of that row across all columns, every column total is the sum of that column across all rows, and the figure in the bottom right is the sum of the whole grid — including the rows and columns that were cut off. That is why a row's Total can be larger than the cells printed beside it.
The number in the header above the table is different on purpose: it counts each issue once. When a field can hold several values at a time — labels, components, versions, sprints — one issue lands in several cells, so the grid adds up to more than the number of issues. The gadget says this explicitly whenever it happens.
An empty cell shows 0 rather than a dash, because zero is an answer.
Shows how far the work under each epic has actually got: done against total, as a progress bar, either by issue count or by any numeric field.
| Setting | What it does |
|---|---|
| Which issues | The issues under your epics, not the epics themselves — progress is measured from the work below each parent. Pick a saved filter or a project and subtasks are excluded for you; with your own JQL, exclude them yourself with issuetype not in subtaskIssueTypes(). |
| Measure progress by | Issue count, or the sum of a numeric field. Story points usually give a truer picture than counting issues, because issues are not the same size. |
| Order | Largest first shows where the weight is. Least complete first shows what is furthest behind. |
| How many parents | How many rows to list. |
An issue counts as done when its status is in the Done status category — the same rule Jira uses to strike through an issue key. Custom statuses work as long as they are mapped to a category, which Jira requires anyway.
Issues without a parent are grouped together under "No parent", so work that escaped an epic is visible instead of silently missing.
Subtasks belong to their story, not to the epic. Jira gives every issue one immediate parent: for a story that is the epic, but for a subtask it is the story. So if your filter includes subtasks, you will see rows for stories alongside rows for epics. The gadget says so when it happens, and the fix is to leave subtasks out of the filter — issuetype not in subtaskIssueTypes() does it in every language and every project type.
Shows where the work currently sits: to do, in progress and done, in workflow order rather than by size, each with its share of the total and the individual statuses behind it.
| Setting | What it does |
|---|---|
| Which issues | A saved filter, a project, or your own JQL — a sprint, a release, a team's backlog. |
| What to measure | Issue count, or the sum of a numeric field. |
Under each stage you also see the statuses that make it up — for example In Progress 3,200 · In Review 1,738 — which is usually where the interesting answer is: work is not stuck "in progress", it is stuck waiting for review.
The two lists of dimensions are not a fixed set. Every time you open the configuration, the app reads the fields that exist in your instance and offers everything it can group sensibly:
Free-text fields such as summary or description are deliberately not offered: they would produce one row per issue rather than a report.
Field names are shown exactly as they appear in your instance, in the language of the person looking at the dashboard.
An issue can carry several labels, components or versions at once. It is counted in every value it has, which is almost always what people want — work tagged both backend and urgent should appear under both. The consequence is that the cells add up to more than the total, and the gadget says so explicitly when it happens.
The app asks for one permission, read:jira-work, and never writes anything to your Jira.
Every calculation runs as the person viewing the dashboard, with that person's Jira permissions. Two people looking at the same gadget can legitimately see different totals if they have access to different projects. The app can never show someone data they could not already find in Jira.
The app runs entirely on Atlassian infrastructure and makes no calls to any external service. It keeps no data of its own — no database, no key-value store, no cache; the only thing that persists is the gadget's own configuration, which Jira stores as part of your dashboard. Full details in the privacy policy.
Those issues have no value in the field you are summing — the field is empty, is not on that issue type's screen, or is hidden from you by a field configuration. They are still counted as issues, but they contribute nothing to the sum. The message tells you how many, so a low total is never a mystery.
Between the moment the app listed the matching issues and the moment it read their fields, some of those issues stopped being readable — typically because someone deleted or moved one, or permissions changed. Rather than show a total that looks precise but is short, the gadget flags it. Refreshing usually resolves it.
Jira's search returns an empty result — not an error — when a filter mentions a field, project or value that does not exist, so a single typo would otherwise produce a confident 0. When a filter matches nothing, the gadget asks Jira to check the filter itself and shows you the reason. If Jira cannot check it at that moment, the gadget says so rather than implying the zero is meaningful.
Yes, and the totals are exact. Percentages are the part to read carefully: a share of a total that mixes positive and negative values can exceed 100% or fall below zero, which is arithmetically right but rarely what "progress" is meant to convey. The progress gadgets flag it when negative values are present; progress bars stop at 100% while the numbers stay exactly as calculated.
They are read when the gadget runs, and Jira's search can take a moment to reflect a change someone made seconds earlier. For a report about where work stands this is invisible; if you are reconciling against an issue you just edited, refresh the gadget.
The list contains every field whose type is numeric. If a field you expect is missing, it is usually either not numeric (a text field holding numbers, for instance) or not visible to your account.
Yes. The app works from JQL and field values, so it does not care how the project is administered.
No. It only reads.
Nothing for sites with up to 10 users. Larger sites get Atlassian's standard 30-day free trial, then a subscription billed by Atlassian alongside Jira itself — there is no separate account and no payment details given to us, and an admin can cancel at any time under Apps → Manage apps. Historical analytics that genuinely need stored data — velocity, time in status, cumulative flow — are not part of this app and are not promised here.
Write to apps@probiusproiect.ro. Support hours are Monday to Friday, 9:00–17:00 Europe/Bucharest, with a target first response within one business day. For anything that looks like a security issue, say so in the subject line and we will treat it as urgent.
When reporting a problem, the two things that help most are the JQL filter you used and what you expected the number to be.