Blog · 3 October 2026

Jira holidays: where to add them, and what each one changes

To add holidays in Jira, open the board, choose Configure board, then Working days, and add each date under Non-working days. That list changes your burndown, sprint and velocity reports, and nothing else. Jira has no single holiday calendar for a whole site: a Jira Service Management SLA keeps its own holidays, Jira Automation knows only Monday to Friday, and a scheduled ticket fires on Christmas Day unless something tells it not to. This guide covers each place, what a holiday there actually changes, and how to stop recurring work from landing on a day nobody is in.

Statements about Jira and Jira Service Management are as of October 2026, from Atlassian's own documentation. Atlassian now calls a project a space and an issue a work item. This guide uses the older words where most admins still do.

The short answer: four places, four different jobs #

None of these four reads the others. A date you add to the board does not pause an SLA, and a holiday in an SLA calendar does not stop an Automation rule from creating a ticket that morning. If your team wants a holiday respected everywhere, it has to be entered in each place that should respect it.

How to add holidays in Jira on a board #

This is the setting most people mean when they search for it. Atlassian describes its scope plainly:

The Working days setting for your board is used for different reports and gadgets.

The reports it lists are the Burndown Chart, Sprint Report, Epic Report, Version Report and Control Chart, plus the Sprint Health and Burndown gadgets. To set it:

1. Go to your board, select More (the three dots), then Configure board.
2. Select Working days.
3. Under Standard working days, tick the days your team normally works.
4. Under Non-working days, pick a date with the date picker and select Add date. Repeat for each holiday.
5. Set the board's Region and Timezone while you are there, because the reports count days in that zone.

You need to be a space admin for the board's location, or an administrator of the board itself.

What it does not do. The board's holidays do not move due dates, do not change a sprint's end date, and do not stop anything from being created. They make a burndown line flat on a holiday instead of showing a day of apparently missed work. That is useful and narrow.

Holidays in Jira Service Management SLA calendars #

A service desk needs holidays for a different reason: an SLA that says "first response in 8 hours" should not breach overnight on a public holiday. Jira Service Management keeps holidays inside SLA calendars, and an SLA goal names the calendar it counts against.

1. From your service space, go to SLAs.
2. Select the calendar icon at the top right, then Add calendar.
3. Name it and choose the time zone.
4. Choose working days and add time slots for each day. Atlassian notes that a new calendar starts at 09:00 to 17:00, and that you can add more than one slot per day to leave out a lunch break.
5. Enter the holidays, then select Save.

You do not have to type a year of dates by hand. Atlassian's knowledge base describes an Import button under Holidays that takes an .ics file, with a warning worth repeating: each event needs a start date, and multi-day events may not be supported. A public holiday calendar exported from Google Calendar or Outlook is the usual source; split any multi-day closure into single days before importing.

One calendar per region is the common pattern. A team split across two countries gets two calendars, and each SLA goal points at the calendar of the people answering it.

What Jira Automation knows about holidays #

Automation has date smart values that sound holiday-aware: {{now.toBusinessDay}}, {{now.firstBusinessDayOfMonth}}, {{now.lastBusinessDayOfMonth}}. Atlassian's smart value reference defines the working week behind them as Monday to Friday, 9am to 6pm.

That is the whole calendar. There is no holiday list behind it and no setting to add one, so lastBusinessDayOfMonth in a December with the 31st on a Friday answers the 31st, whatever your office does that day. The same is true of the Scheduled trigger: it fires on its cron expression or interval, and a cron expression has no field for a public holiday (our Jira cron expression guide covers what one can and cannot say).

The usual workaround, and its cost #

Admins who need a scheduled rule to stay quiet on holidays add a condition after the trigger:

1. Add an Advanced compare condition.
2. First value: a list of dates in one string, such as 2026-12-25,2026-12-26,2027-01-01.
3. Condition: does not contain.
4. Second value: {{now.format("yyyy-MM-dd")}}.

The rule then runs on every day the list does not name. It works. The costs are that the list lives inside one rule, so ten scheduled rules carry ten copies that someone must update every January; that a skipped day is silent, with no ticket and no note saying why; and that the rule cannot move the work to the day before, which is what a "last working day of the month" report actually wants. Moving needs branches and date arithmetic, and that is where most of these rules stop being readable. Our Jira automation examples show where scheduled rules tend to break in general.

Recurring work: skip the holiday, or move it #

For tickets that repeat on a schedule, a holiday raises a question the reports never ask: should this occurrence happen at all, and if so, when? The answer differs per task, even inside one project.

Jira Recurring Work Items handles this with two settings that belong to different people. The project admin writes the calendar once, on the project's settings page under Working days: which weekdays are the weekend, and a holiday list, one date per line as YYYY-MM-DD. Each rule then chooses what happens when its day is not a working day:

• Run on the day it falls on, working day or not. This is the default.
• Move it to the next working day.
• Move it to the previous working day.
• Skip that occurrence entirely.

The steps, end to end:

1. In the project, open Project settings, then Apps, then Recurring work items.
2. Under Working days, tick the weekend days and paste the holiday list. Commas and spaces work as separators too, so a list copied from a holiday website usually pastes straight in; a line that is not a real calendar date is reported on save instead of being quietly dropped.
3. Select Save working days.
4. Open the project's Recurring work items page, create or edit a rule, and pick the working-day option for that task.
5. Read the Next runs preview before saving. It shows the dates the rule will actually use, so a holiday that moves a run is visible before it happens.

A few details that matter in practice. The holiday list belongs to the project, so every rule in it shares one copy and next January's update happens once. A rule that moves backward never moves earlier than its own start date. If a move would have to travel more than 14 days to find a working day, the run happens on its original day, and the run history says so rather than the occurrence disappearing. A due date such as three days after the run is worked out from the day the run actually happens, and when that due date would itself land on a weekend or holiday, any option other than the default moves it to a working day as well (the previous one for a rule that moves backward, otherwise the next). The token reference lists the date tokens a title or due date can use.

This calendar is separate from the board's. It decides when tickets are created. It does not change your burndown, and the board's non-working days do not change it. If you want both, enter the holidays in both places.

You can install it from the Atlassian Marketplace and try a rule in one project; it is switched on per project, so other projects are untouched.

When the manual way is enough #

Not every team needs holidays anywhere but the board.

• You have one or two recurring tickets. Glance at the calendar in December, delete the ticket that lands on the 25th, and move on.
• Your recurring work is fine on any day. Automated checks, patch windows and anything a machine does at night rarely care about public holidays.
• You already run Jira Service Management and the only thing that must respect holidays is the SLA clock. The SLA calendar is the right and complete answer.
• You have a single scheduled Automation rule and a short holiday list. The advanced compare condition above is a few minutes' work and costs nothing extra.

The case for a project-level calendar comes when the list of recurring work grows past what anyone checks by hand, or when "the day before" matters more than "not on the day".

A holiday checklist for the start of each year #

1. Boards: add next year's public holidays and shutdown days under each board's Non-working days, for every board whose reports you read.
2. Service desk: import the new .ics file into each SLA calendar, one calendar per region.
3. Automation: search your rules for scheduled triggers and update any hard-coded holiday lists.
4. Recurring work: paste the year into the project's working-days list, then scan each rule's Next runs preview for the dates that moved.
5. Write down where you entered them. Because no place reads another, the next admin needs the list of places as much as the list of dates.

For more on keeping a project's routine work on rails, see Jira recurring tasks and Jira scheduling.