How long has this work item spent in each status?

Where it appears#

• A panel on the work item view, titled Statuswatch and labelled Time in status. Jira renders it collapsed, so the history appears when the panel is opened.

• A project settings page, also titled Statuswatch, under Apps in the project's own settings. Saving requires project administration or Jira administration rights, which the app checks itself before writing.

What the panel shows#

One row per status, largest first: the name, the total time, and a bar showing that status's share of the total. Rows carry the status's current name rather than the name recorded at the time, so a rename keeps one row. Where the counted rows cover more than one status category, a rollup above them totals the time in each. It comes from those same rows, so a finished item rarely carries a done figure, and one that went straight from to do to done shows no rollup.

Read the bars as shares, not progress. Together they span what the panel counted: creation to now, or to the moment the item was done, in working hours where the project uses them. The caption above them says as much, and says the clock stops at Done. Every item has its own total, so bars are not comparable between items.

A status the item is in now carries a current lozenge; one entered more than once carries a count, such as 3×. Each status name opens the stays that add up to its total: when each began, how long it lasted, and when it ended, or that the item is still here. A stay whose mover the changelog names says so; one it does not — including the stay the item was created in — says set on creation.

The footer gives the denominator — Total time since creation:, or Total time to done: where the clock stopped — and under it the number of status changes. Durations are truncated down, so rows can look as though they do not quite add up.

When the item has a due date, a line above the status rows shows how much time is left, counted the same way as the rows below. Past the due date it turns red and counts the overrun instead; on a finished item it says whether the item made it. Lateness is judged by the clock, not by working time, so an item can be marked late with no duration beside it.

How time is counted#

By default the panel counts calendar time, around the clock, so an item left over a weekend collects it. The toggle labelled Count business hours only lets a project admin set working days, start and end times, an optional break, holidays and a time zone. A project can hold several calendars, chosen by work type, component or label: the first is the fallback, the rest are tried in order, and the first match wins.

Under business hours a day means a working day, not twenty-four hours: on a 09:00–17:00 project, 1d is eight hours.

With business hours on, a line reading Counted in names the calendar the numbers were measured under, and that name opens a dialog spelling out its rules — including, where the project chooses calendars by a field, why this one applied.

While an item sits in a done-category status the clock is stopped: the closing run of done statuses is left out of the rows and the total, and the caption and footer then say the total runs to Done. A closed item therefore usually shows no Done or Closed row, and none carries the current lozenge. An item that has only ever been in a done status keeps its row: there is nothing to leave out.

When something cannot be read#

Rather than show a figure that looks ordinary, the panel warns above the numbers when something could not be read: the project's working hours, and the times are then calendar time; the item's full history, and the earliest part of it is missing; or status names and categories, and a renamed status may show its old name. It shows one warning at a time, in that order. In place of the panel it can also show No status history for this issue yet. or Could not read this issue history.

What it deliberately does not do#

• No reporting across items, no dashboard gadget, no export.

• No calendars per assignee, since the statuses where waiting hurts most usually have no assignee.

• No connection to SLAs. An SLA runs against a goal; Statuswatch only counts.

• No country holiday calendar. Holidays are a list the admin keeps.

• No changes to your data. The app holds no write scope.

Cost, permissions and data#

Statuswatch is free, and asks for two scopes. read:jira-work covers the item and its status changelog, the project's statuses, the permission check made before a save, and the settings page's own lookups. storage:app covers its settings record. Every Jira call is made as the signed-in user, so the panel shows only a history that person could already read.

There is no external egress: no remote backend, no analytics, no third party. The only thing stored is one calendar configuration per project — no account identifiers, no work item content, nothing that identifies a person; uninstalling removes it. Names from the changelog appear in the per-status detail but are not stored.

The rest of this documentation#

Other pages cover the panel row by row, working hours and calendars, due dates, the warnings, and permissions and privacy.