There's no native report for this in Codebeamer — cbQL doesn't expose transition duration as a filterable/groupable field, and there's no out-of-the-box "time in status" or "cycle time between states" report or gadget. It's a two-part build.
1. Capture the duration on the item
Add two hidden date/time fields (e.g. EnteredStatusA, EnteredStatusB), and use a Change Handler on each relevant transition to stamp the current time into the matching field when the item enters that status. A computed field then does the subtraction in JUEL:
dflt((EnteredStatusB - EnteredStatusA) / 3600000.0, 0)
Note: Swap the divisor for the unit you want: 86400000.0 for days, 60000.0 for minutes.
This only captures items going forward, since Change Handlers don't run retroactively on existing history.
2. Backfill historical items
Existing items already have this data sitting in their version history. GET /v3/items/{itemId}/history returns the full versioned change log per item, so you can walk it to find the version where Status changed to A and the version where it changed to B, and diff the timestamps. Script this once per tracker to populate the same fields for items that already exist.
3. Report on it
Once duration is a plain numeric field on the item, a standard Table Report or Chart gadget with an Average aggregation (grouped by tracker, release, etc.) gives you the tracker-wide average — no plugin required at that point.
One thing worth deciding up front: if an item can cycle back through Status A (rework loops), decide whether you want first-entry-to-first-entry, cumulative time spent in A, or the last occurrence only. That ambiguity is what trips up most home-grown cycle-time implementations, in Codebeamer or otherwise.
Brian Kampling | Source Allies Inc. | Systems Engineering Consultant
