Guide
Working hours and calendars
How durations are counted
By default Statuswatch counts calendar time: an issue that enters a status on Friday evening keeps collecting time over the weekend. With business hours on, only the minutes inside a working window on a working day are counted; nights, non-working days, the break and holidays are skipped.
When the issue has a due date, a line under the deadline says which of the two produced the numbers.
Under a calendar, a day means a working day, not twenty-four hours: if the working day is eight hours, 1d 4h is twelve working hours. A working day is the working window with the break taken out.
If the working hours cannot be read, the panel falls back to calendar time and says so in a warning above the figures.
When the clock is paused
When the moment you open the panel falls outside the calendar — a night, a non-working day, a holiday or the break — the panel says so and gives the time counting resumes: On a break in this calendar. The clock is paused, counting again today at 13:00. It is information, not a warning: the figures are correct and simply are not moving. On a finished item it does not appear, since nothing is accruing there in any case.
Seeing the hours behind a number
With business hours on, the panel carries a link after the words "Counted in" — "this project’s working hours" when no rule is set, otherwise "the name calendar". It opens a dialog listing the working days, the hours, any break, the length of a working day, the time zone and the holidays. With business hours off there is no link and no dialog.
Turning working hours on
Settings are per project: open the project's own settings and find Apps → Statuswatch. Jira labels that section Project settings or Space settings depending on the site.
Saving needs project administration permission on the project, or Jira administration permission, checked on every save. A save is also refused when someone else saved while your page was open — reload to see their version, then make your change again.
The switch is the toggle "Count business hours only", off by default. The rest of the form appears once it is on, and Save writes the change. Directly under the toggle sits the rule that chooses which calendar applies, which is set once for the whole project. Everything below that belongs to one calendar: a project that holds several gives each its own working days, hours, break, holidays and time zone.
Working days
Under "Working days", tick any of the seven days. A project's first calendar starts with Monday to Friday.
Day starts and Day ends
"Day starts" and "Day ends" are dropdowns in quarter-hour steps, with a final 24:00 so a round-the-clock calendar can be set exactly. A project's first calendar starts at 09:00–17:00. A calendar with no working day, or an end at or before its start, is refused on save and named.
The break
"Lunch break" has a "From" and a "To", both optional and both clearable; leave both empty for no break. Only the part of a break inside the working window is taken off the day. A break with one end left empty, or one lying outside the window altogether, counts as no break and shows no Break row in the dialog.
Holidays
"Holidays" is a free text box, one entry per line:
2026-12-24 Christmas Eve— that one date.12-25 Christmas Day— 25 December in every year.- A line starting with
#— a comment: stored, shown again next time, ignored when counting.
Save refuses a line that is not a date and names it. Dates are checked against the real calendar, so 2026-02-30 is rejected, while a recurring 02-29 is accepted. A holiday removes the whole day, not part of it.
Time zone
"Time zone" sets the zone in which the working window, the break and the holiday dates are read. It also fixes when a due date falls due: the end of the working window with business hours on, midnight without. A due date is never moved off a weekend or a holiday. A project that has never been configured starts from the time zone your browser reports.
More than one calendar in a project
A project can hold several named calendars and one rule for choosing between them. The rule is the field "For this project, apply calendars by", with four options:
| Option | What it looks at |
|---|---|
| Nothing — one calendar for everything | Nothing. Only the first calendar applies. |
| Work type | The issue's work type. |
| Component | The issue's components. |
| Label | The issue's labels. |
Below it sits the "Calendars" table, showing what each calendar applies to. Editing happens one calendar at a time under "Edit calendar": a picker chooses which, "Add calendar" makes another, and "Remove" deletes any calendar except the first. A new calendar copies the first one's settings, and claims nothing until you give it values.
How a calendar claims issues
With a rule set, every calendar except the first has a field "Applies to these work types" (or components, or labels). The values are picked from a list of what the field actually holds, not typed, and subtask work types are not on that list. Labels are listed site-wide, since Jira keeps no per-project list; on a site with very many labels the list is cut off, the field says so, and a label past the cut-off cannot be attached at all.
Calendars after the first are tried in order, and the first one claiming a value the issue carries wins. Matching ignores letter case and surrounding spaces, so a stored support still matches a component named Support.
Which calendar applies is read from the issue's work type, components and labels as they stand now, and the durations are recomputed each time the panel opens. Relabelling an issue, or editing a calendar, changes the numbers for its whole past history.
The fallback
The first calendar is the fallback: it claims nothing of its own and applies to every issue no other calendar claims. In the picker its name is followed by "(fallback)". In the table its row reads "Everything else", followed by any values no calendar has claimed — "Everything else, including Platform".
With the rule set to "Nothing — one calendar for everything", the table says so: the first calendar covers every issue in the project and the others are not in use. With a rule set, the dialog behind the "Counted in" link also says why that calendar applied.
Why not per assignee
One rule governs the whole project. Choosing by assignee is deliberately not offered, and the settings page gives the reason: Jira knows a person's time zone but not their hours, the assignee changes over an issue's life, and the statuses where waiting hurts most usually have no assignee at all.