Help
Frequently asked questions
Statuswatch adds one panel to the Jira work item view: how long the item has spent in each status. This page answers the questions we are asked most often, not everything the app does.
Where does the panel appear?
On the work item view, in a collapsible section headed Statuswatch, collapsed by default. Working hours are set on a separate project settings page, also called Statuswatch, under Apps in the project's settings. There is no report page and no dashboard gadget.
What is on the panel?
From the top: a line explaining the bars, a due-date countdown if the item has a due date, a rollup by status category once the item has been in more than one category, one row per status, and the total, which runs from the item's creation timestamp.
Does it change anything in Jira, and what does it cost?
It changes nothing: the app holds two scopes, read:jira-work and storage:app, so it cannot alter a work item, a workflow or a status. The only thing it writes is one working-hours record per project. It is free — the manifest declares no licensing, so there is no paid tier, trial or licence key.
Does it count nights and weekends?
By default, yes. Switching on Count business hours only limits every duration to the hours you configure, and the panel then says when the clock is paused for a night, a weekend, a holiday or the break. With it on, the panel adds a Counted in line that opens the schedule it used, and a day in the durations means a working day, not twenty-four hours.
What can a project admin set?
The settings page starts with that one switch, and everything else appears once it is on: a rule, For this project, apply calendars by, offering Nothing — one calendar for everything, Work type, Component and Label; and the calendars themselves. Left at Nothing there is one calendar for the whole project; choose one of the other three and you can add more, each claiming values picked from that field. The first calendar is the fallback; the rest are tried in order, and the first match wins.
Each calendar carries its own Working days, Day starts, Day ends, optional Lunch break, Time zone and Holidays — one per line, as 2026-12-24 Christmas Eve or 12-25 to repeat every year. No country calendar ships with the app.
Why does a status show 0m, and why is nothing counting?
Statuses the item has never been in are listed too, at 0m with an empty bar, taken from the item's own work type's workflow — what it skipped is often as telling as where it waited. 0m also appears on a status the item is genuinely in when every minute so far fell outside working hours; <1m means a real but unmeasurably short stay, so the two say different things.
When the current moment is outside the calendar, the panel adds a note giving the reason and the time counting resumes — a holiday, a non-working day, the evening, or the lunch break.
How do I tell where the item is now?
By the marker beside the status name: a blue current while the clock is running, a green done once it has stopped on a finished item. The second is deliberately not current — the figure beside it is an earlier stay in that status, and nothing is being added to it.
Can I get the numbers out of the panel?
Yes. The project settings page has two export buttons, both producing CSV in minutes: one for time in status across the work items created in the last 90 days, capped at 200 and stated when the cap bites, and one for the working-hours calendars themselves. There is no report page and no dashboard gadget — the panel and these two files are the whole of it.
What does "Longer than all 14 stays this project has had in this status" mean?
That this work item has now been sitting in that status longer than any completed stay the project has had there. The number is how many completed stays were found to compare against, and the median tells you what is normal: half of them were shorter than that, half longer.
It compares against the project, not against this work item's own history, and only against stays that ended. It appears only while the clock is running, only with at least five stays to compare against, and only when the current stay is genuinely out of the ordinary — so on most work items you will never see it.
What does the length of a bar mean?
A bar is that status's share of the item's total measured time, not progress towards a target. Bars are therefore not comparable between items — 50% on a two-hour-old item and 50% on a six-month-old one look identical — and only the figure beside the bar says how long that status lasted.
Why do the rows not add up to the total?
Every duration is shown to its two largest units and truncated down — 6d 3h 59m reads as 6d 3h — while any sum adds the exact values and truncates once. Four rows reading 46m, 5m, 3m and 2m can therefore sit under a total of 58m.
What about a work item that never changed status?
It still gets a panel. Jira's changelog omits such an item entirely, so the app measures from its created date to now, and the footer reads Never changed status.
What happens when a work item is resolved, or reopened?
On a resolved item the trailing run of done-category statuses is dropped, so the total stops where the item first reached done and the footer switches to Total time to done:. The whole run goes, so sweeping an item from Done to Closed does not move the finish. An item that has only ever been in done statuses has nothing to drop, so its total keeps running.
Reopen it and counting resumes, with the footer back to Total time since creation:; the done stretch it has now left is kept. A status entered more than once shows its visit count beside the name, and clicking the name lists each stay, its length and who moved the item in.
Does it work in Jira Service Management? Is it tied to SLAs?
It works in Jira Service Management projects as well as in company-managed and team-managed software projects. It sits on the work item as agents see it and never appears in the customer portal. It has no connection to SLAs.
What about a very long history?
The app pages through the changelog rather than reading only the first page — up to twenty pages of a thousand entries. Beyond that it warns above the numbers that the earliest part of the history is missing.
We renamed a status. Which name shows?
The current one, looked up from the status id, so the item's history stays in one row instead of splitting into an old name and a new one.
What if the working hours are wrong, or cannot be read?
With business hours on, a save is refused rather than storing a calendar the app cannot measure with, and the offending calendar is named: Default: pick at least one working day and an end time after the start. A holiday line that is not a date is named back the same way, and a save is refused if someone else saved while the page was open.
If the stored configuration cannot be read at all, the panel warns above the figures that the times below are calendar time, nights and weekends included.
Where is the data stored, and who can change the settings?
One record per project in Forge storage: whether business hours are on, the calendar rule, the calendars themselves and a revision number. It holds no account ids and no work item content — only the settings an admin entered or picked — and uninstalling removes it. Work item data is read as the panel renders and never leaves Atlassian.
Saving needs the project's Administer projects permission or the site-wide Administer Jira permission, which the save checks for itself. Every call to Jira is made as the signed-in user, so the panel cannot show a history the viewer could not already read.