.webp)
Nobody Told the SLA Clock It Was Labor Day
Labor Day exists because of people who worked too much. President Grover Cleveland signed it into law on June 28, 1894, and the first Monday in September has been a federal holiday in the United States ever since. It is a day about rest, granted under considerable duress.
Somewhere in your organization, a person spent part of today looking at a phone.
That is not automatically a failure. Someone has to hold the pager on a long weekend, and the people who do it deserve better than an afterthought. It becomes a failure when nobody decided it on purpose — when the coverage that happened this weekend was the coverage your Jira Service Management configuration happened to produce, rather than the coverage anyone chose.
Long weekends are the closest thing a service desk gets to a free load test. Today is a good day to read the results.
The SLA clock runs unless you tell it not to
Atlassian’s documentation on setting up SLA calendars is direct about this: in Jira Service Management, service level agreement clocks run 24/7 by default, and if you want to exclude weekends, breaks, or holidays, you attach a calendar to the goal. A service space ships with two calendars out of the box — a Default 24/7 calendar, which is used whenever no calendar has been assigned to a goal, and a Sample 9-5 calendar. Calendars you create yourself start preset at 09:00 to 17:00, and from there you set working days, add multiple time slots per day, and enter holidays.
Read that with an operational eye. The default is not “business hours.” The default is always. Every SLA goal in your instance where nobody explicitly picked a calendar has been counting since Friday afternoon.
For a genuine severity-one incident commitment, that is correct behavior and you should leave it alone. For a time-to-first-response goal on a laptop request submitted at 4:40 PM on the Friday of a holiday weekend, it produces a breach that tells you nothing about your team and quietly poisons the number your leadership reviews next quarter. If you want the fuller picture of how goals, queues, and automation interact, we walked through the way SLAs, queues, and automation actually wire together in Jira Service Management earlier this year.
Holidays are a list, and lists rot
Here is the part that gets missed. Holidays in a Jira Service Management SLA calendar are entries on that calendar. Not a national holiday feed. Not something inherited from your human resources system. A list, maintained per calendar, that somebody populated once and that nobody has been asked to look at since.
Now multiply that by the regional calendars you built so the team in Bangalore is not measured against a Chicago work week, and by the number of years since anyone opened them. Holiday lists are a maintenance task disguised as a configuration setting, and maintenance tasks without an owner become September surprises.
This is the mundane explanation for a conversation many platform owners have had: the SLA numbers dipped in early September, everyone assumes the team got slower, and the actual cause is that a clock counted 72 hours nobody was being paid to work. We made a version of this argument before summer in our guide to getting the Atlassian stack ready for vacation season, and the September version is the same problem wearing a jacket.
The clock and the rotation are two different systems
Worth separating two things that get conflated in the same breath. The SLA clock measures whether you met a commitment. On-call scheduling determines whether a human finds out in time to try.
Atlassian’s documentation on on-call schedules notes that when a team launches operations in Jira Service Management, the product automatically creates a first on-call schedule, routing rule, and escalation policy. That is a generous starting point, and it is also exactly the kind of default that survives for three years because it works well enough on a Tuesday.
The detail worth testing is the fallback. Atlassian documents that even when a rotation resolves to no one being assigned, escalation policies and routing rules still direct urgent alerts to an appropriate recipient. A safety net exists. The question is whether anyone in your organization can name where it lands. Long weekends are how teams discover that the final escalation target is a person who changed roles in March, or a distribution list that three people muted. For a wider view of how this fits into the current incident tooling, see our look at Atlassian’s Service Collection and its incident command model.
If your rotations still live in Opsgenie, mark April 5, 2027
There is a second calendar problem, and it is a larger one. According to Atlassian’s support documentation, Opsgenie reaches end of support on April 5, 2027. On that date access is switched off, the Opsgenie REST APIs stop responding, and data that has not been migrated is permanently deleted. Only migrated content — alerts, on-call schedules, escalation policies — arrives in Jira Service Management. Atlassian ended new Opsgenie sales on June 4, 2025, and sites where Opsgenie came bundled with Jira Service Management were handled on a separate track that closed in October 2025; those teams are already on the alerting and on-call capabilities built into Jira Service Management itself.
Eighteen months sounds generous. In practice it is one budget cycle, one platform-team hiring gap, and two holiday change freezes. Migrating rotations is not difficult work, but it is work that competes with everything else, and the failure mode is not a dramatic outage — it is arriving in early 2027 with escalation policies nobody has validated. This is the same arithmetic we ran on the Data Center end-of-life deadline, and it lands the same way: the date is not the deadline, the last safe start date is.
While you are in there: change windows and stale ownership
Two adjacent things worth ten minutes each.
Jira Service Management includes a change calendar and change windows. Holiday weekends are exactly when you want deployments constrained and exactly when nobody remembers to constrain them. If your organization observes an informal freeze that lives entirely in a Slack message from 2024, that is a policy with no enforcement surface.
Second, approvals. A change or service request routed to a single named approver is a coverage gap wearing a governance costume. It works flawlessly until that person is at a lake with no signal, at which point your carefully designed workflow is a request sitting in a status.
Both of those depend on knowing who owns what, which is a configuration management problem more than a service desk one. Atlassian has been investing there, including moving Assets out into its own platform application. Ownership data that is accurate in the abstract but eleven months stale in practice will fail you on precisely the weekend you needed it.
Who should care, and who genuinely should not
- Teams with real 24/7 severity-one commitments: your 24/7 clock is correct. Spend the time on the rotation and the escalation fallback instead.
- Internal service desks with business-hours commitments: you are the most likely to be quietly misreporting. This is worth an hour.
- Global organizations: one holiday list is wrong for somebody. Regional calendars are not gold plating; they are the difference between a real measurement and a fictional one.
- Teams without formal service level agreements: skip all of this. Do not invent commitments because Jira Service Management has a field for them. An unmeasured process that works is better than a measured one nobody believes.
What to actually do this week
While the weekend is still fresh enough to check against:
- Pull the SLA goals in your busiest service space and list which ones have no calendar attached. Those are running 24/7 whether you meant it or not.
- Open each calendar you do use and look at the holiday entries. Note the last year anyone added to them.
- Find the breaches logged between Friday evening and this morning. Sort them into “we genuinely missed this” and “the clock was measuring an empty office.” The second pile is your work item.
- Trace one alert through your on-call configuration to its final escalation target. Confirm that target is a person who still works there.
- If you are still on Opsgenie, put a real migration start date on the roadmap rather than a reference to April 2027.
- Give the holiday list an owner and a recurring reminder. Ninety seconds of ceremony beats next September’s postmortem.
The Avaratak Take
The instinct after a quiet long weekend is relief, and the instinct after a loud one is to blame the rotation. Both skip the useful step. A holiday weekend is unplanned chaos engineering that your organization gets for free three or four times a year: reduced staffing, unusual load patterns, and every assumption in your configuration tested at once without anyone scheduling a game day.
The teams that get value from that treat holiday breach data as evidence rather than noise. They come back and ask which of those breaches were real. Almost nobody does this, because on the Tuesday after a long weekend there are 340 tickets in the queue and nobody has appetite for archaeology. That is precisely why the ninety-minute version of this audit, done once a year, outperforms the platform review that keeps getting scheduled and cancelled.
There is also a non-technical version of the point, and on this particular holiday it seems worth saying plainly. Somebody covered the weekend. The platform’s job is to make sure that was a decision somebody made, with a defined scope and a defined end, rather than an accident of a default nobody revisited. Configuration is how an organization expresses what it actually expects of people. It is worth being deliberate about what yours is saying.
The unglamorous version
None of this is hard. It is a calendar, a list of dates, an escalation chain, and one honest look at a breach report. It is also the kind of work that never wins a roadmap slot, because “audit the holiday calendars” has not excited a steering committee in the history of steering committees. Do it anyway. Thanksgiving is eleven weeks out, and the December stretch is worse.
If you want a second set of eyes on how your Jira Service Management coverage model holds up when the office is empty, Avaratak’s senior Atlassian consultants do this kind of review regularly. You can book a discovery conversation or find us at avaratak.com.