Blog · 5 October 2026

Jira on-call rotation: schedules, handover tickets, paging

A Jira on-call rotation is really three jobs that people lump together. The first is deciding who is on duty this week and paging them when something breaks. The second is making the rotation fair, so the same person is not on duty every holiday. The third is the part nobody builds: a record that each shift started, was handed over and was closed. Jira Service Management covers the first job with on-call schedules. Plain Jira covers the third if something creates the ticket on time. This guide sorts out which tool does which, and when a simple rotation is enough.

Statements about Atlassian's features and prices are as of October 2026, read from Atlassian's own pages.

What "on call" means in Jira #

Jira Software and Jira Work Management have no concept of a person being on duty. An issue has an assignee, and that is all. If you want "whoever is on call this week gets the alert", the answer lives in a different product: Jira Service Management.

Atlassian describes it like this:

An on-call schedule is a collection of rotations that define when different team members are responsible for handling incidents and alerts.

A rotation is where the turn-taking happens:

Rotations are groups of people who take turns being on-call for a specific shift.

So the vocabulary is: a schedule holds one or more rotations, each rotation has participants and a shift duration, and the schedule shows who is on call at any moment.

Three ways to run a rotation #

Pick by what happens when the person on duty is not reached.

These are not exclusive. A team with a paging tool still needs the handover ticket, and a team with only a calendar still needs a place to record what happened.

Option 1: Jira Service Management on-call schedules #

If outages page people, use the real thing. Atlassian's pricing page lists "Alerts, on-call schedules, and incident template" in the Free plan, which it describes as free for 3 agents. Beyond that, the Standard plan is listed at $20 per agent per month and Premium at $51.42 per agent per month. Check the page for your own team size before you commit, because the agent count is what drives the bill.

The documented setup is short:

1. Go to the schedule where you want the rotation and select Add rotation.
2. Enter a name and add the participants.
3. Under Timings, choose a shift duration, or create a custom one.
4. Set the frequency: daily, weekly or a custom cycle.
5. Save, and read the schedule preview to check who is on call and when.

Atlassian describes a schedule as three layers: a Base layer with the planned shifts, an Overrides layer for swaps and substitutions, and a Final layer showing who was actually on call. That last layer is what you want when someone asks, three weeks later, who had the pager on the night of the outage.

One detail from the same page is worth remembering when you set shift times: the start of the day is 12:00 am, which may not be when your working day begins. Adjust the timings to your own hours.

Option 2: a plain rotation, no paging #

Plenty of teams are "on call" in the sense of owning the support queue for a week, or watching the deployment pipeline during business hours. Nobody is paged at 3 a.m. For that, a rotation is a list of names and a start date.

A workable version:

• Write the order of names in one place the team already reads, such as the project's description or a pinned wiki page.
• Pick a handover day and time. Monday morning is common because the new person starts with a fresh week.
• Agree on a swap rule: you can trade shifts if you both tell the team before the shift starts.
• Keep holidays in mind. If the handover falls on a public holiday, move it to the next working day, and say so up front.

This costs nothing and works for as long as somebody remembers to announce the change. That reliance on memory is the weak point, and it is exactly what a recurring ticket fixes.

Option 3: a recurring ticket for every shift #

Whichever tool decides who is on call, you can make Jira hold the record. The idea is simple: every shift is a ticket. It is created automatically when the shift starts, assigned to the person taking over, and closed when the shift ends. The description carries the handover checklist.

A good shift ticket contains:

• The handover checklist: open incidents, pending changes, things to watch this week.
• Links to the runbook and the dashboards.
• A subtask list for the routine checks the shift owes, such as confirming backups ran or reviewing the overnight alert summary.
• A due date at the end of the shift, so an unclosed ticket shows up as overdue.

The benefits are practical. A shift that nobody closed is visible on the board. The history of who held each shift is a filter away. And the person coming on duty gets a ticket in their queue instead of having to remember to look at a wiki.

Creating the shift ticket automatically #

You can create the ticket by hand every Monday, which works until the Monday someone is out. Jira Automation can do it with a scheduled trigger and a Create work item action. We compared the options in Jira recurring tasks, and the limits to keep in mind are in Jira Cloud automation limits.

Recurring Work Items for Jira is our app, and this is the kind of job it does. You write a rule once in the project: a weekly schedule, a template with a summary, description, assignee and priority, and a list of subtasks for the handover checklist. Titles can carry dates through tokens, so each shift ticket is named for its own week, for example with {{rule.name}} and the date of the run.

It also has the properties an on-call routine needs:

• Real time zones. A run has a wall-clock time in a real time zone, so a 09:00 handover stays at 09:00 through a clock change.
• A working-day calendar per project. A rule can run anyway, move to the next working day, move to the previous one, or skip, so a handover that falls on a holiday does something you chose.
• A due date stored as an expression. Each ticket gets its own due date, such as a number of days after it is created.
• A run history. Every run is recorded as created, skipped or failed, with a reason.
• No Jira Automation quota. The rules run on the app's own scheduler.

Rotating the assignee #

The honest limit: a rule in the app assigns to one person, the one you set in the template. It does not rotate through a list for you, and it does not page anyone. If your rotation has four people, there are two ways to cover it.

Offset rules. Make one rule per person. Each rule repeats every four weeks, and each has a different start date: week one, week two, week three, week four. The editor has an "every N" setting and a start date, so the four rules interleave into one continuous rotation. Name them after the person, so the rules table reads like the schedule. When someone leaves or a person is added, you edit the rules and the next runs panel shows you the effect straight away.

One rule, reassigned by the person. Create a single weekly rule assigned to a team lead, and have the incoming person take the ticket at handover. This is less automatic, and it is the better choice when the rotation changes often.

Neither is as good as a dedicated schedule when your problem is paging. They are good when your problem is that the handover does not happen.

Putting the two together #

If you use Jira Service Management for paging, let it own the answer to "who is on call right now". Then let a recurring ticket own the record. The two have different jobs and the combination covers the gap each one leaves:

When the simple way is enough #

Do not build a rotation system you do not need. Stay with a calendar and a wiki page if:

• Nobody is paged outside business hours.
• The team is three or four people who talk every day.
• A missed handover costs a delayed reply, not an outage.

Move to an on-call schedule when an alert has to reach a human within minutes. Add the recurring shift ticket when you notice that handovers get skipped, or when somebody asks you to prove who was on duty. For the routine work that sits around the rotation, such as access reviews and backup checks, see Jira for IT operations, and for the reminder side of the problem, Jira reminder.

Summary #

• Paging belongs to Jira Service Management's on-call schedules. Plain Jira has no on-call concept.
• A calendar and a wiki page are a fine rotation when nobody is paged out of hours.
• A recurring ticket per shift gives you the handover and the record, whichever tool decides who is on duty.
• Offset rules give you a rotating assignee from a scheduling app that assigns one person per rule.
• Check Atlassian's pricing page for your own agent count, since the Free plan is limited to 3 agents.