Time in previous status

Configuration

To use the Time in previous status template, simply select it from the template grid. Filter by Process compliance & flow health to find it faster.

Parameters

This template does not require any additional parameter configuration.

Edit formula mode

Expression

Jira expression:

let statusChangelogs = issue.changelogs.filter(changelog => changelog.items.some(item => item.fieldId == 'status' && item.from != item.to)); statusChangelogs[0] ? (statusChangelogs[0].created.getTime() - (statusChangelogs[1] ? statusChangelogs[1].created : issue.created).getTime()) : null

Display as

Duration

Formatting style

Default (unformatted)

Details

1. What does the expression do?

This parser expression calculates how long the current work item spent in its previous status (i.e., the status it was in right before the current one). If the work item has never changed status, it returns no value (so the template can display “None”).

2. Step-by-step breakdown

Expression (from the page):

let statusChangelogs = issue.changelogs.filter(changelog => changelog.items.some(item => item.fieldId == 'status' && item.from != item.to)); statusChangelogs[0] ? (statusChangelogs[0].created.getTime() - (statusChangelogs[1] ? statusChangelogs[1].created : issue.created).getTime()) : null

Step A — Collect only “status change” history entries

• issue.changelogs = the work item’s change history (changelog entries).

• .filter(...) keeps only those changelog entries where:

  • .items.some(...) = at least one change item inside that entry matches the condition.

  • item.fieldId == 'status' = the changed field is the status field.

  • item.from != item.to = it’s a real status change (not a no-op).

Result:

• statusChangelogs becomes a list of changelog entries that contain actual status transitions.

Step B — Check whether any status change exists

• statusChangelogs[0] ? ... : null

  • statusChangelogs[0] means: “do we have at least one status change entry?”

  • If no, return null (no previous status exists).

  • If yes, calculate a duration.

Step C — Calculate “time spent in previous status”

The duration is computed as:

• End time = when the work item entered the current status
  → statusChangelogs[0].created.getTime()

• Start time = when the work item entered the previous status, which is:

  • If there is a “change before the last change”:

    • statusChangelogs[1].created

  • Otherwise (meaning the work item has only ever changed status once):

    • issue.created (the work item’s creation time)

So the core calculation is:

• timeEnteredCurrentStatus - timeEnteredPreviousStatus

Notes:

• .getTime() converts a date/time into a numeric timestamp (milliseconds). The field is displayed as Duration, so it will be rendered as a time span.

3. Examples

Example 1 — Work item changed status multiple times

• Created: May 1, 09:00

• Moved to “In Progress”: May 2, 10:00

• Moved to “Done” (current status): May 5, 15:00

Then:

• statusChangelogs[0].created ≈ May 5, 15:00 (entered current status)

• statusChangelogs[1].created ≈ May 2, 10:00 (entered previous status)

• Result = time spent in “In Progress” = ~3 days 5 hours

Example 2 — Work item changed status only once

• Created: May 1, 09:00

• Moved to “In Progress” (current status): May 3, 12:00

There is no statusChangelogs[1], so it uses issue.created:

• Result = time spent in the initial status (e.g., “To Do”) = ~2 days 3 hours

Example 3 — No status change yet

• Work item is still in its initial status

• statusChangelogs is empty

• Result = null (template shows “None”)

4. Real-life use cases

• Process compliance checks: Identify work items that spent unusually long in the previous step (e.g., stuck in “In Review” before moving to “Done”).

• Flow efficiency analysis: Spot bottlenecks by comparing “time in previous status” across many work items.

• Team performance coaching: Highlight where handoffs take too long (e.g., “Ready for QA” → “In QA” transitions).

• Operational monitoring dashboards: Show how long items spent in the last stage before the current one, to detect slowdowns early.

If you tell me whether your instance sorts issue.changelogs newest-first or oldest-first in your environment, I can also confirm whether this expression is measuring the immediately previous status exactly as intended (it assumes the list order where index [0] is the most recent status change).