Reports and dashboards
Reports are read-only charts computed from an item's history, on a project's own page or server-wide. Dashboards let you assemble your own page of report and query widgets.
The server computes every report on the fly, from the item history and the event log. Nothing is pre-aggregated, so a report always reflects the current state. Each report also respects what you can see. A cross-project report only counts projects you can read, and states the scope when it is not everything.
You can narrow any report with the page's own SLQ filter bar — the item
query language, the same one views use. The filter matches items right
now. A filter of assignee = me reports the history of items currently
assigned to you. It does not record who was assigned at each past event.
Open a project and click Reports.
| Report | What it shows | Counts | Date range |
|---|---|---|---|
| Throughput | Items finished per bucket, as a bar chart | Items that entered a done-category state in the bucket | A From/To range you set (default: the last 30 days), bucketed by day or week |
| Cumulative flow | How many items sat in each state category, per bucket | A snapshot at the end of each bucket, not movements during it | Same From/To range and bucket width as Throughput |
| Burnup | Scope versus completed, for one cycle | Items (or points) assigned to the cycle each day, and items (or points) completed by that day | The chosen cycle's own start and end dates |
| Time in state | Average and median hours items spent in each state category | Only completed stays — a state the item has since left, not the one it is in now | All time; optionally narrowed to epics, issues, or subtasks |
| Velocity | Items (or points) completed per cycle | The last N completed cycles, N set by you | No date range — a count of recent completed cycles |
| Service desk | Weekly SLA outcomes: response and resolution met versus breached, plus average satisfaction rating | Items with SLA activity, bucketed by the week the item was created (satisfaction ratings bucket by the week the reply was sent) | The last N weeks (default 12, up to 26) |
Open Reports from the sidebar. It carries Velocity, Burnup, and Service desk — the three reports that make sense across every project. Throughput, Cumulative flow, and Time in state need one project's state history to mean anything, so they stay on each project's own Reports page.
Throughput counts the day an item finished, not the day it shipped. This is the report most often misread, so it is worth stating plainly.
A project that uses the release pipeline has a Waiting for release state in the done category, positioned directly before Done. An item's move into that state is what throughput counts: work that is complete but has not shipped yet. A release later sweeps the item into Done. Throughput does not count that second move. Both states share the done category, and a move between two states in the same category is not a new completion.
The dashboard below shows this on real data. Waiting for release (1) holds work that is finished and not yet in a release. Items delivered (948) counts everything in the done category, shipped or not.
Both reports read from cycles. Both can measure in item counts, or in story points where a project has turned points on. See Time logging and the timesheet for how points are set.
- Velocity looks at the most recently completed cycles. For each one, it totals what entered a done-category state while assigned to it. It spans every project you can read, because cycles are not confined to one project.
- Burnup plots one cycle's scope (what was assigned to it, day by day) against what was completed, over the cycle's own scheduled window. A cycle with no start and end date has nothing to plot — schedule it first.
A dashboard is a page you assemble yourself from widgets, each backed by a report or a query you already have access to.
To create a dashboard:
- Click New dashboard in the sidebar's Dashboards section.
- Enter a name.
To add a widget:
- Open the dashboard and click Add widget.
- Select a widget type.
- Fill in its settings and save.
| Widget | Shows |
|---|---|
| Throughput | The Throughput report for one project |
| Cumulative flow | The Cumulative flow report for one project |
| Time in state | The Time in state report for one project |
| Velocity | The Velocity report (last N cycles, count or points) |
| Burnup | The Burnup report for one chosen cycle |
| Service desk | The SLA report, for one project or across every project |
| Count | A big number: how many items match an SLQ query |
| List | A compact list of items matching an SLQ query (up to 20) |
| View count | How many items are in one saved view |
A widget that reads from a project or a view you cannot see renders as "Unavailable" instead of breaking the rest of the dashboard.
To arrange the grid, use the toolbar that appears over a widget while editing. It sets the widget's width — one, two, or three columns of the 3-column grid — and moves the widget up or down. You need editor or owner access to this dashboard to see this toolbar.
Dashboards use the same access framework as views. A new dashboard is visible only to its creator. Click Share to grant access. Two options exist:
- Grant specific people, teams, or groups a level: viewer, editor, or owner. Owner level is co-ownership: a co-owner can manage sharing and delete the dashboard, not only edit it.
- Turn on visibility for every active user, at viewer or editor level. This
needs the
dashboard.createpermission atom, because it broadcasts the dashboard to the whole server.
A dashboard that is not shared with you is invisible. You get the same "not found" result as anyone else, and this applies to administrators too. A person with editor level or owner level can edit a widget's definition. Only an owner-level person can share or delete the dashboard.
TODO(verify): whether a plugin can currently contribute its own widget type on this instance — the mechanism exists in the code but no such plugin was available to confirm against a live example.
Mirrored from project.radd-hq.com on 2026-09-12. Documentation is written there; this copy is regenerated by scripts/publish_wiki.py and hand edits do not survive it.