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 calendar", at the end of the calendar's fields, or "Save all", at the foot of the page, writes the change. They do the same thing: the settings of a project are saved together. 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.
The week view
Above the fields, under "Edit calendar", the calendar you are editing is drawn as a week, the way a calendar app draws one. Each day is a column, the hours that count are blue blocks labelled with their times, a break is the gap between two blocks, a day nobody works is grey and says "Closed", a holiday is grey with its name in place of the hours, and a red line marks now. The line above the week says how much the week counts in all, for example "36h 15m counted this week", and which time zone the times are in. The arrows move a week back or forward, which is how you check that a holiday next month lands where you meant it, and "Today" comes back.
You can also edit there. Drag the top or the bottom of a block to change when it starts or ends; edges move in quarter hours. Double click a free spot to add a block, an hour long, and click a block and press Backspace to remove it. A day can have up to four blocks, and the gaps between them are its breaks. Removing a day's only block makes it a day nobody works, and a double click on such a day makes it a working day again. Every one of these changes that weekday in every week, which is the same setting as its row under "Some days have different hours", so that section opens to show what changed and "Reset" takes it back. A holiday is a date and not a weekday, so its column is not edited in the week view.
The picture follows the form at once, before you save: tick Saturday and a Saturday block appears. It is drawn from the same rules the measurement uses, so the week's total is exactly what a work item open for that whole week would be counted as. When the form has a mistake that would stop the calendar from counting, such as a day that ends before it starts, the week view is withdrawn until the mistake is fixed.
Every time field opens its list at the time it shows, in order from 00:00 to 24:00, and typing "16" jumps to 16:00.
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.
Days with different hours
Tick "Some days have different hours" and every working day gets a row of its own, showing the hours and the breaks that day has now. Change a day's start, its end or a break (a Saturday desk from 10:00 to 12:00 with no break, a Friday that ends at 15:00) and that day keeps the change as its own; its name turns bold, and "Reset" takes the change back. Changing one thing is enough: whatever you leave alone stays what every day has, and goes on following the calendar's hours and break when those change. "Add a break" gives a day a second or third break, half an hour in the middle of its longest stretch, for you to move; clear both fields of a break to remove it. A day whose hours or a break end before they start, whose break has only one end, or whose breaks overlap, is refused on save and named.
Once days differ, the panel's hours dialog lists each day instead of one line of hours, and "A working day, on average" gives the unit the panel's "1d" stands for: the week's working time divided by its working days, so that five days are still one working week. A due date falls due at the close of its own day's hours.
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 a day's working window is taken off that day, so a Saturday that closes at 12:00 loses nothing to a 12:30 lunch. 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
#is a comment: stored, shown again next time, ignored when counting.
"Import from an ICS file" reads the holidays out of an iCalendar file, the format public-holiday calendars are published in. Open the .ics file in a text editor, paste all of it into the box and choose "Add to holidays": each event becomes a line in the list, an event that repeats every year becomes a recurring line, a multi-day event becomes a range, and what is already listed is not added twice. The result is reported, for example "3 added, 1 not usable (no date, or repeating other than yearly)." Nothing is saved until you press Save. The file is read where you paste it; Statuswatch fetches nothing.
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.
Using the same calendar as Jira Service Management
Jira Service Management keeps its own calendars for SLAs, and Jira gives apps no way to read them, or to export them. They are quick to copy, because both are built from the same parts: open the calendar under Space settings → SLAs → calendar icon, set the same time zone and the same hours per day here, and import the same ICS file for the holidays. One difference: a Jira Service Management day can have several separate periods, where a day here has one period and a break. When the calendar in Jira Service Management changes, change it here too.
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 that day's 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, as in "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.