Guide
Working hours in Jira Automation
The calendar a project admin keeps in Statuswatch is, on most Jira sites, the only place that knows when the team works. Three steps make it available to Jira Automation, so a rule can count in the same working hours as the panel: the same project record, the same choice of calendar by work type, component or label, the same breaks and holidays.
The three steps
| Step | What it answers | A rule that uses it |
|---|---|---|
| Add working time | The date and time at which a number of working days, hours or minutes has passed since a start. | When a work item is created, set Due date to three working days later. |
| Working time between | The working time between two moments, exactly as the panel counts it. | Every hour, escalate items that have waited more than eight working hours. |
| Business hours check | Whether working time is running at a moment, and when it next starts. | Hold a notification until someone is there to read it. |
They are found in the rule builder under Add an action, by name. The first time you add one, Jira asks you to press Connect. That is Jira's own consent step for actions provided by an app: the step then reads the work item as you, so it can never count on an item you could not open. One connection covers all three steps.
What to fill in
Every field takes text or a smart value.
- "Start", "End" and "Moment" take a date smart value such as
{{issue.created}}, or text like2026-08-12or2026-08-12T09:30. Text without a time zone is read on the calendar's own wall clock. Left empty, they mean the moment the rule runs. - "Amount" takes a number or a smart value; half days work (
0.5). "Unit" is "Working days", "Working hours" or "Working minutes". A working day is the calendar's window less its break: seven hours for 09:00–17:00 with an hour's lunch. - "Work item" is pre-filled with
{{issue.key}}and decides whose working hours are counted: the calendar the panel names on that item. For rules that run on no work item there is "Or a project key", which uses the project's fallback calendar.
What comes back
Each step's results are smart values for the steps after it.
| Step | Smart values |
|---|---|
| Add working time | {{fetchedStatuswatchWorktime.date}}, .time, .dateTime, .calendar, .timeZone |
| Working time between | {{fetchedStatuswatchBetween.minutes}}, .hours, .workingDays, .formatted, .calendar, .timeZone |
| Business hours check | {{fetchedStatuswatchHours.isWorkingTime}}, .reason, .nextOpening, .nextOpeningDate, .nextOpeningTime, .calendar, .timeZone |
date and time are read on the calendar's wall clock, because a due date is a date where the team sits: 23:30 UTC on the 11th is the 12th in Berlin, and the 12th is what belongs in Due date. dateTime is the same moment in the format Jira's date-time fields are edited with. To set a due date, use Edit work item after the step and give Due date the value {{fetchedStatuswatchWorktime.date}}.
Measurements are rounded down, never to the nearest. An item 42 seconds short of three working days reads 2.99, so a rule that waits for three does not fire early.
When a step fails, and why it is meant to
A rule has no screen. The panel can put a warning above a number it could not count properly; a rule has nowhere to put one, and a due date quietly counted in calendar time would be found weeks later, by someone wondering why it fell on a Sunday. So a step that cannot count in working hours sets nothing: it fails, the rule's audit log shows Action failed due to invalid input followed by the reason, and the steps after it do not run.
- "No working hours are switched on for project …" Switch them on under Project settings → Apps → Statuswatch.
- "The start could not be read as a date …" The field holds something that is not a date; the message quotes what it found.
- "The end (…) lies before the start (…)." The two fields are swapped. It is refused rather than answered with nought, because a rule comparing a waiting time against a limit would pass a swapped pair for ever and look healthy doing it.
- "Statuswatch could not act for the person this step is connected as …" Open the rule, select the step and check its connection.
- "The work item or project could not be read …" It does not exist, or the person the step is connected as may not see it.