Leading Signal: Resonate Documentation

Setup (first run)

Open Resonate from your Jira project page.
Select your board and choose which columns count as active work (for example, "In Progress" and "In Review"). Leave "To Do" and "Done" inactive, they aren't cycle time.
Choose how far back to look for resolved tickets, the benchmark window (default 35 days, five sprints).
Save. The dashboard computes your first benchmark automatically.

The Dashboard tab

The live view. Shows the benchmark chart and every currently open ticket.

The WIP chart

Each column on your board is shown as a stack of coloured bands. The bands represent cumulative cycle time percentiles: how long tickets typically take to reach the end of that column, based on resolved tickets in your benchmark window.

Each dot is a live ticket. Its vertical position shows how long it has been in the workflow. Dots cluster when many tickets are at similar ages; that density is itself a signal.

The bands get warmer as a ticket ages, from green through to red. The one exception is the line at the top: cross it and a ticket is off the scale.

Band	Colour	What it means
≤ p50	Green	Flowing, faster than half of historical tickets
p50–p70	Gold	Slowing, still normal but worth watching
p70–p85	Orange	At risk, starting to take longer than most
p85–p95	Red	Needs attention, in the slowest 15%
> p95	No fill above a red line; the dot gets a red ring	Off the scale, slower than 95% of your history. An outlier to look at individually, not a systemic problem
No data	Grey	No benchmark data for this column yet

Resonate follows your Jira appearance setting. It renders in light or dark to match the rest of Jira, and switches with it.

The ticket lists

Below the chart, tickets split into two groups.

Needs attention: tickets above p70. Worth a look in your next standup or triage. Shows which status a ticket is stuck in and how long it's been there, how far it's aged past the relevant threshold (for example, "+2.1d over p85"), and who owns it.
On track: everything at or below p70. A compact list of key, summary, column, age, and assignee.

What to action

Signal	Likely cause	Action
Many orange/red dots in one column	Bottleneck, work is queuing here	Look at WIP limits; ask what's blocking the column
One or two red-ringed (> p95) dots	Individual blockers	Escalate or decompose; these are outliers, not systemic
Dots spread evenly across all columns	No obvious bottleneck	Good, review Insights to check if overall cycle time is trending up
Grey dots everywhere	Benchmark not yet computed	Click Refresh

Refresh recomputes the benchmark from scratch using Jira's changelog. It updates the chart, the ticket bands, and the Insights tab all at once.

The Insights tab

Historical metrics for the benchmark window. These numbers describe resolved tickets, work that actually finished, so they're more reliable than snapshot data.

Period stats

Metric	What it means
Median cycle time	The p50, half your tickets finished faster than this, half slower. Your baseline.
85th percentile	Your informal SLA. 85% of tickets finished within this time. Cross it and a ticket is in the slowest 15% of your history.
Throughput	Tickets closed per week over the benchmark window. Pairs with cycle time: if throughput falls while cycle time rises, work is genuinely slowing down.
Tickets closed	Total resolved tickets that contributed to the benchmark. Low numbers (under 10) make all percentiles unreliable, extend the benchmark window.

Where time is spent

Shows where time is actually going. Each active status is listed with the average time a ticket spends there and its share of total cycle time, across your resolved tickets. The longest bar is your biggest bottleneck.

Example: In Review: 2.9 days (59%) means that on average, 59% of a ticket's total journey is spent waiting in review.

What to action:

If one status dominates (over 50%) and it's a waiting state, like "In Review" or "Waiting for QA", that's your primary bottleneck, not the work itself but the handoff.
If time is spread evenly across many statuses, there's no single bottleneck; look at reducing overall WIP instead.
Compare against your own sense of where work gets stuck. If the data disagrees, investigate why.

Rework impact

Splits resolved tickets into two groups and compares their average cycle time: tickets that flowed straight through the workflow, and tickets that moved backward at least once (for example, from "In Review" back to "In Progress"), along with how many tickets fall in each group.

A ticket moves backward when it returns to an earlier status. Backward movement adds cycle time and is the clearest signal of unresolved quality issues.

A wide gap between the two averages, with a meaningful number of tickets in the backward group, points at handoff problems: incomplete definitions of done, missing acceptance criteria, or unclear review expectations.
A small backward-group count is a good sign on its own, but check whether it's trending up over time, not just its size in this window.
Zero rework isn't always the goal; some rework is healthy iteration. Watch for trends, not absolute numbers.

The Settings tab

Change your board selection, active columns, subtask inclusion, or benchmark window. Saving settings doesn't automatically recompute the benchmark, go to Dashboard and click Refresh to update all metrics.

A Danger Zone at the bottom lets you reset all Resonate configuration and benchmark data for the project. This is not reversible, use it only if you want to start over from scratch.

Glossary

Cycle time: The time from when a ticket enters the first active column to when it leaves the last active column (reaches Done). Resonate measures active time only; inactive statuses like "To Do" and "Done" are excluded.
Benchmark window: The number of calendar days back to look for resolved tickets when computing percentiles. Default is 35 days (five sprints). Shorter windows reflect recent behaviour more closely; longer windows are more statistically stable. Needs at least about 20 resolved tickets for meaningful results. It means "the last N days ending today," and rolls forward the next time you refresh. The Insights tab shows exactly when a benchmark was last computed.
Percentile (p50, p70, p85, p95): If you have 100 resolved tickets sorted by cycle time, p50 is the value at position 50, p85 at position 85, and so on. They're thresholds, not averages. p85 being 12 days means 85 out of 100 historical tickets finished within 12 days.
Throughput: Tickets closed per week. Calculated as total tickets divided by (benchmark window in days divided by 7). Doesn't distinguish ticket size or type.
Rework: Any backward status transition in a ticket's history (for example, "In Review" back to "In Progress"). Resonate banks the time spent in a status before a backward transition and restores it if the ticket moves forward again, so rework time is tracked but doesn't inflate cycle time artificially.
Cumulative age: The sum of time a ticket has spent in active statuses, excluding banked rework time. This is the number used for band assignment and shown in the dashboard.

Tips

Benchmark window too short? If Tickets closed shows fewer than 20, your percentiles are unreliable. Switch to a longer window (56 or 91 days) in Settings.
First benchmark looks wrong? The benchmark only uses tickets resolved after Resonate was installed and configured. Give it at least one sprint before drawing conclusions.
Throughput dropped but cycle time is the same? Work may have gotten larger or more complex, or team capacity changed. Resonate measures flow, not output quality, use it alongside your existing planning process.
Metrics spiked after a holiday or freeze period? Resolved tickets from an unusual period (end of quarter, release freeze) can skew percentiles. Shorten the benchmark window to exclude them.

Something not covered here?

Email us.

[email protected]