Report fields: filters, queues, dashboards and your own reporting

The panel answers a question about one work item. A filter, a queue, a board or a reporting tool asks about many, and none of them can open a panel. For those, Statuswatch can write its count into Jira itself, as fields on the work item. It is off until a project administrator switches it on.

The two figures#

Both are read-only and locked: nobody can type into them, and writing them leaves no entry in the work item's history and does not change its Updated date. They exist on the site from the moment the app is installed, and stay empty in every project that has not switched them on.

Is that a long time? The verdict fields#

"In Review for 6d 4h" is a measurement, and a measurement does not tell you whether to worry. Six days in review is routine in one team and a fire in the next, and the only honest yardstick is the project itself. Two more fields carry that comparison, so a filter can ask the question the panel answers.

The basis is there because the verdict on its own is not a whole claim. "Longer than all" over five past stays and over five hundred are different statements, and whoever reads the column in a report has no panel in front of them to say which one this is.

"Not enough history" is an answer, not a blank. A status needs five completed stays in the project before a comparison means anything; below that Statuswatch says so rather than leaving the field empty. That matters for anyone filtering on it: "Time in status verdict" is EMPTY means nothing was counted, because the work item is finished or the project has the fields off, and never "nothing is wrong here".

The comparison is the same one the panel makes on the work item, and the same one the Statuswatch agent makes when you ask what is stuck. It judges the stay that is running, not the total across earlier visits: a work item back in Review for the second time is judged on the hours since it came back.

These two are written by the hourly refresh only, not when you open a work item, because the comparison needs the whole project's history and that is too much to fetch on every view. So they can be up to an hour older than the figures beside them, never newer.

A field for every status you report on#

The two fields above say how long a work item has been sitting where it is now. A report usually asks something else: how long did Review take, over everything we finished last quarter? For that there is a field type, "Time in status (Statuswatch)", from which a Jira admin creates as many fields as there are statuses worth reporting on.

1. In Jira settings → Work items → Fields, create a custom field and pick the type "Time in status (Statuswatch)". Name it after what it counts, for example Time in Review.
2. Open the field's context and choose Edit custom field config. Under "Status to count" pick the status and save. It is matched by name, so it covers every workflow that has a status called that.
3. Add the field to a screen of the projects you report on. Jira leaves a field out of the work item's data, and out of JQL, until it is on one of the project's screens.

The field then holds the minutes the work item spent in that status, all its visits together, counted in the working hours of the work item's own project. Unlike Time in current status it keeps its figure when the work item is done, because that is when a report wants it. A work item that never entered the status stays empty rather than 0: an average over a column of zeros would say Review takes no time, when what happened is that most items skipped it.

Finished work is counted too, not only what closes from now on: each hourly run takes up to 300 finished work items per project that were never counted, newest first, and "Refresh now" reports them as "finished items counted for the first time". These fields follow the same switch as the other two and stay empty in projects that have not turned on "Write report fields".

Switching them on#

Under Project settings → Apps → Statuswatch, in the section "Report fields", turn on "Write report fields" and save. The figures are then refreshed every hour, and whenever a work item showing the field is opened. "Refresh now" runs the refresh at once and reports what it did, for example "12 counted, 0 cleared because they are done." A run covers up to 1,000 open work items per project and says so when it stopped there; the rest follow in later runs.

Switching it off again stops the counting. Figures already written stay where they are, with the date they were counted.

The fields are available in company-managed Jira Software projects and in Jira Service Management projects. Team-managed projects do not show them.

What you can do with them#

• Filters and JQL. "Time in current status" > 2400 finds everything that has sat in its status for more than 40 working hours; is EMPTY, is not EMPTY and ORDER BY work too. The figure is in minutes.
• What is unusual, without picking a number. "Time in status verdict" in ("longer than all", "longer than 9 in 10") asks for work items that are slow for this project, with no threshold to guess and none to maintain as the team gets faster. Add "Time in status verdict" = "not enough history" to see what could not be judged.
• Queues, boards and lists. Add the field as a column and sort by it. In Jira Service Management that puts the longest-waiting request at the top of a queue, counted in your team's hours.
• Jira dashboards. Any gadget that takes a filter or a number field can use it.
• Jira Automation. A scheduled rule with that JQL and a Send email action tells the assignee when a work item has been in a status too long, in your own words, to your own recipients, over email, Slack or Teams. With the verdict field in the JQL it fires on what is unusual for the project rather than on a fixed number of hours. See Working hours in Jira Automation.
• Power BI, Tableau, Excel and other reporting tools. Statuswatch sends nothing outside Atlassian and offers no endpoint of its own. But a custom field is part of the work item, so whichever Jira connector you already use (with your own credentials, under your own control) reads these fields like any other.

Who counts, and what that means for permissions#

Everything else in Statuswatch reads Jira as the person looking at the screen. This one part cannot: the hourly refresh runs with nobody signed in, and Jira asks for a field's value without saying who is looking. So the report fields are counted by the app, for every open work item of the project, whether or not any particular person may see it.

No figure reaches anyone that way who could not already see the work item: a field's value is visible exactly where the work item is. The app still holds no write permission for Jira; it can set the value of its own fields and nothing else.

When a figure is missing or old#

• Empty on a finished item: as intended. Reopen it and it is counted again within the hour.
• Empty on an open item: the project has not switched the fields on, the refresh has not run yet, or the project is team-managed.
• A figure that did not move: when the working hours could not be read, Statuswatch leaves the last figure and its date as they were rather than overwriting them with calendar time, because a number in a column has nowhere to put a warning. Time in status counted as of shows how old it is.
• A verdict that says "not enough history": the project has completed fewer than five stays in that status, so there is nothing to compare against. It is not a fault, and it is not an all-clear.
• An empty verdict on an open item: the same three reasons as an empty figure, plus one. If either the working hours or the status names could not be read, the verdict is left untouched rather than guessed, because a comparison drawn across two different rulers is worse than none.