In development · Built on Atlassian Forge

Find out where the time actually goes.

Calibro Pulse reads the changelog your issues already carry and turns it into cycle time, throughput, and the one thing a board cannot tell you: which stage of your workflow is slower than its own normal, and by how much.

Not released yet. Registering tells us to email you when it is — nothing else.

The whole thing, then a piece at a time

The first frame is the dashboard as you get it. The rest are the same screens close up — every widget on its own, because a chart with its legend cropped off says less than no chart at all.

The Calibro Pulse dashboard in full: headline, four stat tiles, workflow health table, needs-attention queue, cycle time and throughput charts, and a work distribution bar.

The whole dashboard One question, answered at four depths: the headline names the problem, the tiles size it, the table locates it in the process, the queue names the issues.

Four stat tiles: median cycle time 6.4d up 1.1d, throughput 11 per week up 2, aging WIP 9 issues, blocked 5 issues.

The four numbers Median cycle time, throughput, aging work in progress and blocked — each with what it was doing before, not just what it is now.

The workflow health table with QA and Blocked highlighted in amber, each row showing its share of cycle time, median, issues in stage and distance from normal.

Which stage is the problem Every measured stage with its share of one cycle. A row only turns amber when it is slower than its own 90-day norm — never for being the slowest.

The needs-attention card listing blocked issues with their key, status lozenge, assignee and how long they have been in stage.

The queue behind the number Three orderings of the same work in flight — blocked longest, in progress longest, over cycle time — because the same issue is usually all three.

A line chart of weekly median cycle time rising over twelve weeks, inside a shaded percentile band, with a break where one week had no completions.

Cycle time, with its spread The weekly median with a 15th-to-85th percentile band. The gap is a week where nothing finished — drawn as a gap, not a line through it.

A stacked bar splitting 60 active issues across To do, In progress, Code review, QA and Blocked, with a note that 28 percent is in QA and Blocked.

Where the work is sitting Active issues by the stage they are in right now, and the one sentence that matters underneath.

A line chart of weekly median time in the QA stage, climbing above a dashed line marking the 90-day norm of 1.3 days.

Open a stage: is it drifting? The same stage week by week against its 90-day norm, so a slow stage that has always been slow looks different from one that changed.

Two cards breaking the QA stage down: median time by assignee, and by issue type showing bugs sitting more than twice as long as anything else.

Then: why “QA is slow” is not actionable. Median time in stage split by who held it and by what kind of work it was, usually is.

The Stages table listing every workflow status with its role, position within one cycle, median, count in stage and distance from normal.

Every status, including the unmeasured ones Each bar is one whole cycle and the highlight is where that stage sits inside it. Backlog, Done and excluded statuses are listed too, marked as not measured.

The workflow mapping screen: each Jira status beside a dropdown choosing whether it starts cycle time, ends it, counts as in flight or blocked, or is excluded.

Your workflow, not ours Tell it which status starts the clock and which stops it. Changing a role recalculates history rather than losing it.

Screenshots show sample data, not a real customer's instance.

Nothing is stored

There is no metrics database. Every figure is recomputed from your Jira changelogs at the moment you open the page, which is why changing how a status is counted recalculates history instead of losing it.

Compared against itself

A stage is flagged when it is slower than its own 90-day norm — never for simply being the slowest. And the baseline ends where the period begins, so a slowdown can't quietly become part of its own normal.

Medians, with the mean beside them

Cycle times are heavily skewed; one ticket that sat over a holiday moves a mean by a day and a median not at all. The average is shown next to the median because the gap between them is the signal.

It reads your statuses, not ours

Roles are inferred from Jira's own status categories, so the first open is already right on a workflow nobody has configured. Rename a column or run Jira in German and nothing breaks.

An unknown is not a zero

A stage nobody left this period has no median, and it renders as —. A week where nothing finished draws a gap in the chart. A dashboard that shows "couldn't tell" as "none" stops being believed the first time somebody checks.

Nothing leaves your site

Built entirely on Atlassian Forge, like Track, Sketch, Explore, Prioritize and Plan. Your issues are read and counted inside Atlassian's infrastructure — there is no server of ours for them to travel to, and Pulse only ever reads.

It isn't finished, and we'd rather say so.

Calibro Pulse works — the screenshots on this page are the real interface, not a mockup — but it is not on the Marketplace and there is no date on it yet.

The thing we most want to hear is whether the measurement matches how your team actually works. Cycle time is easy to compute and easy to compute wrongly, and the projects it gets pointed at are the only way to find the workflows we haven't thought of.

So: no launch date, no waiting list theatre, no drip campaign. One email when there's something to install.

Where it's up to

Cycle time, throughput, blocked work Working

Per-stage drill-down and trends Working

Workflow mapping and baselines Working

Sprint-scoped periods Needs Jira Software

Marketplace listing Not started

Want it?

Leave an address and we'll tell you when it's installable. That's the whole commitment — for you and for us.