Setting it up

Statuswatch adds one panel to the Jira work item view and one page to a project’s settings. This page takes an administrator from installing it to a project counted in that team’s own working hours.

Before you install#

Statuswatch is a free Forge app for Jira Cloud, for Jira Software and Jira Service Management projects. On Jira Service Management the panel appears in the agent view only; it does not render in the customer portal.

The app declares two permissions and no others:

No data leaves Atlassian: no remote backend, no analytics, no third party. The record holds only the configuration — the switch, the rule, the calendars, and a revision counter that detects two administrators saving at once. No account identifiers, no user names, no work item content.

Step 1: open a work item#

Nothing has to be switched on after installation. Open any work item in a project you can browse. The panel is titled Statuswatch; Jira may also show its label, Time in status. It starts collapsed, and nothing is read until you expand it.

Every bar is that status’s share of the work item’s total time; the footer repeats that total and the number of status changes. Once the clock has stopped at Done, both switch from time so far to time to done. A work item that has never moved reads Never changed status. One with a due date also gets a countdown above the bars, which says whether it counts working or calendar time.

Until working hours are configured the numbers are calendar time: an item left over a weekend collects the weekend. The panel does not warn about it.

Step 2: open the project’s settings#

The page lives in the project’s own settings, under Apps → Statuswatch. Jira labels that section “Project settings” or “Space settings” depending on the site.

It opens with a note that the panel counts calendar time by default, and a switch labelled Count business hours only.

The calendar fields#

Turning the switch on reveals them. A project that has never been configured starts at Mon–Fri, 09:00–17:00, no break and no holidays, in the browser’s own time zone rather than UTC.

• Working days, as seven checkboxes.
• Day starts and Day ends, as quarter-hour choices up to 24:00.
• Lunch break, with From and To. Leave both empty for no break.
• Holidays, one per line: 2026-12-24 for a single date, 12-25 to repeat every year. Anything after the date is a name; a line beginning with # is a comment.
• Time zone.

Press Save; success shows ✓ Saved. A calendar with no working day, or an end time before its start, is refused and named rather than stored, as is a holiday line that is not a date.

More than one calendar#

Switching business hours on already shows a Calendars table — columns Calendar and What applies — and an Edit calendar section. With no rule set the table holds one row: Default, Every issue in this project.

Above the table, For this project, apply calendars by starts on Nothing — one calendar for everything. Choosing Work type, Component or Label adds a Calendar picker, an Add calendar button and a Calendar name field.

The first calendar is the fallback, and under its name the page reads This one applies whenever no other calendar claims the issue. Every calendar after it has instead an Applies to these work types field — or components, or labels — with values picked from what the field has rather than typed, and a Remove button.

Calendars are tried in order and the first that claims the work item wins. Jira keeps no per-project label list, so under Label the values offered are the whole site’s.

Who is allowed to change the settings#

Project administrators. Before writing anything, the app checks whether the signed-in user holds ADMINISTER_PROJECTS on the project or ADMINISTER on the site — either is enough, because a Jira administrator does not always hold the project permission. A user with neither gets You need to be a project admin to change this., and an error from Jira is treated as a refusal.

Such a user still sees the panel in full. What anyone sees there is bounded by their own Jira permissions, because every read is made as them.

If two administrators have the page open at once, the second save is refused rather than allowed to overwrite what the first did: Someone else saved these settings while this page was open. Reload to see theirs, then make your change again.

Configuration is per project#

Working hours are a team fact rather than a site fact — support covers Saturdays, the platform team does not — so they are stored per project, and configuring one changes nothing in another.

One warning at a time can appear above the numbers:

• This project’s working hours could not be read just now, so the times below are calendar time — nights and weekends included.
• This issue has more status changes than the panel can read, so the earliest part of its history is missing.
• Status names and categories could not be read just now, so a renamed status may show its old name.

When the history cannot be read at all, plain text replaces the numbers — Could not load the status history., Could not read this issue history. or No issue in context. A work item whose creation timestamp cannot be read shows No status history for this issue yet.

Once business hours are on, the panel says so under its first line: Counted in, then this project’s working hours while no rule is set, or the calendar’s name once one is — for example the Default calendar. That name opens a dialog giving the days, hours, any break, the length of a working day, the time zone and the holidays. It gives A working day in real hours, because under a calendar a day means a working day rather than twenty-four.

Exporting the numbers#

At the foot of the settings page sit two buttons. Both produce a CSV file, in minutes, and neither changes anything.

Export time in status covers the work items created in the last 90 days, newest first, up to 200 of them. One row per work item, one column per status, and a final row of averages — each status averaged over the items that actually entered it, since an item that never reached a status says nothing about how long that status takes. The durations are counted in whichever calendar applied to each item, so a project with several calendars exports each item under its own.

If more than 200 work items fall in that window the page says so after the export rather than quietly handing you a partial file.

Export calendars writes out the working hours themselves as they stand on the page, including unsaved edits: name, what each calendar applies to, working days, hours, break, time zone and holidays. It is the record of how the numbers were reached, which is the part that is hardest to reconstruct from memory later.

Minutes rather than 1d 4h, and the unit is in every column heading. Under a calendar a day is a working day, so a column of days cannot be added up without knowing how long that day is.