Blog ·
Jira for IT operations: the board, the queue, and the routine
Jira for IT operations works when you split the work by where it comes from. Requests and incidents arrive from other people, so they belong in a queue with a clear intake. Projects and changes are planned, so they belong on a board. And then there is the third kind, the one most ops teams never put anywhere: the routine. Patch the servers every month, check the backups every week, review who has admin access every quarter, renew the certificates before they expire. That work comes back on a clock, and it only shows up on a board if somebody remembers to create the ticket. This guide covers all three, and spends most of its time on the third, because that is where ops teams lose work quietly.
Statements about Jira's built-in features are as of October 2026, from Atlassian's own documentation.
Three kinds of work, three homes #
Most ops teams start with one Jira project and pour everything into it. Within a month the board is a mix of password resets, a data centre migration and a monthly patch run, and nobody can tell from a glance what is urgent.
| Kind of work | Where it comes from | Where it lives in Jira | What matters most |
|---|---|---|---|
| Requests and incidents | Other people, any time | A service project queue | Fast intake, a quick first reply |
| Projects and changes | Your own plan | A board, with epics | Owners, dates, approvals |
| Routine operations | The calendar | The same board, created on a schedule | It happens every cycle, on time |
The routine is the row that goes missing. Requests force themselves onto the board because somebody is waiting. Projects get tickets because they are planned. Routine work is the same every time, so it lives in someone's head or a wiki page until the week that person is on leave.
Set up the request queue #
If people outside the team ask IT for things, give them one front door. Jira Service Management is Atlassian's product for that: a portal where people raise requests, and a queue where your team works them. If your company does not use it, a plain Jira project with a "Request" work type and an email channel is a reasonable start.
Either way, keep the intake small:
- a handful of request types (access, hardware, software, "something is broken"), each with only the fields you need to act;
- one queue sorted by age, so nothing waits silently at the bottom;
- a label or component for the system affected, so a filter can show every open item against the VPN or the mail server.
The queue is not where your planned work should go. A migration ticket sitting between two password resets gets triaged like one.
Set up the board for planned work #
Create a separate project, or a separate board on the same project filtered to planned work, for everything your team decides to do. A short workflow covers nearly all of it:
| Status | What it means |
|---|---|
| To do | Agreed and scheduled for this period |
| In progress | Somebody is doing it now |
| Waiting | Blocked on a vendor, an approval or a maintenance window |
| Done | Finished and checked |
Keep "Waiting" as one status with a reason in a field or label, rather than a status per blocker. Ops work blocks on many things, and a column for each turns the board into a museum of stuck tickets.
Projects such as a network refresh or an OS upgrade become epics, with a task per site or per system. Changes that need approval follow your change process; our Jira change management template covers the fields and flow for normal, standard and emergency changes.
The routine operations nobody creates a ticket for #
Here is a typical ops calendar. Every row is work that has to happen whether or not anyone remembered:
| Routine | Typical cadence | What goes wrong without a ticket |
|---|---|---|
| Patch servers and endpoints | Monthly, after the vendor's release day | Slips a month when the team is busy |
| Verify backups restore | Weekly | Backups "run" for months without anyone testing one |
| Review admin and privileged access | Quarterly | Leavers keep access; the auditor finds it first |
| Check certificate and domain expiry | Monthly | An expired certificate takes a site down on a Sunday |
| Review licence and contract renewals | Quarterly | A renewal auto-charges or lapses |
| Rotate shared credentials and API keys | Every 90 days or per policy | Keys outlive the people who knew them |
| Capacity and disk usage review | Monthly | A full disk becomes an incident |
| Disaster recovery test | Twice a year | The runbook is out of date when it is needed |
Each of these is small, and that is exactly why they slip. A routine with a ticket has an owner, a due date and a record that it was done. A routine without one has a hope.
A recurring ticket also helps when an auditor asks. "Show me that access was reviewed every quarter last year" is answered by a filter: four resolved tickets, each with a date, an assignee and the notes from that review.
How to create recurring ops tickets in Jira #
There are three honest options. The right one depends on how many routines you have and who will maintain the rules.
| Clone by hand | Jira Automation scheduled rule | A scheduling app | |
|---|---|---|---|
| Who creates the ticket | A person, every cycle | A rule | A rule in the project |
| Setup per routine | None | A rule, often with a cron expression | A rule, in a form |
| "Second Tuesday of the month" | Whoever remembers | Needs a cron expression | Chosen in the form |
| Weekends and holidays | Whoever notices | Handled in the rule's logic, if at all | Set once for the project |
| When someone is away | Not created | Created on time | Created on time |
| Cost | Time | Counts toward your plan's automation usage | App licence |
Option 1: clone by hand #
Keep a "master" ticket for each routine with the checklist in the description, and clone it each cycle. It costs nothing and is fine for a team with two or three routines and one person who reliably owns them. It fails in the week of a major incident, which is the week the backup check matters most.
Option 2: a Jira Automation rule #
Jira Automation's Scheduled trigger can create a work item on a timer. Atlassian's trigger reference, as of October 2026, says you can "run the flow at a fixed rate (for example, every 7 days), or use a Cron expression for more complex schedules." A weekly backup check is easy. Patch Tuesday style schedules ("the Wednesday after the second Tuesday") need cron, and some ops cadences cannot be said in cron at all; our Jira cron expression guide covers the syntax and those gaps.
Two things to know before you build a dozen of these. First, each run counts toward your plan's automation usage, explained in Jira Automation pricing. Second, the same Atlassian page says:
Scheduled flows that reach a Failure status for 10 consecutive executions will disable automatically.
For a quarterly access review that means a broken rule can go quiet without anyone noticing, so check each rule's audit log on a schedule of its own. Our Jira automation examples article walks through where scheduled rules tend to break.
Option 3: a scheduling app #
Recurring Work Items for Jira is our app, and recurring routine work is the job it was built for. An ops routine becomes a rule in the project:
- Turn the app on for the ops project and choose who may schedule.
- Set the working week and add public holidays, so a rule can move off a day the team is not working rather than creating a ticket nobody will see until Monday.
- Create a rule for each routine. The schedule options are every N days, chosen weekdays every N weeks, a day of the month every N months, or a weekday position such as the second Tuesday or the last Friday of the month.
- Write the title with tokens so each ticket has its own name, for example
Patch run {{now.monthName}} {{now.year}}. - Put the checklist in the description or as subtasks, and set the assignee, labels and due date as an offset from the run.
It uses no Jira Automation quota, because the scheduling is the app's own. Each created or failed run is written to the rule's history with its reason, so "why is there no backup ticket this week?" has an answer you can read. A rule is scoped to the one project it lives in, so the ops team's schedules never create tickets in anyone else's project. It is free for up to 10 users.
A starter set of recurring ops rules #
A set most teams can adopt on day one. Adjust the cadence to your own policy:
- Weekly backup restore test, every Monday, due Wednesday. Description: which system to restore this week, where to restore it, how to confirm the data, and where to record the result.
- Monthly patch run, on the second Tuesday of the month, due a few days later. Subtasks per environment: test, staging, production, endpoints.
- Monthly certificate and domain expiry check, on the 1st, due within the week. Description: the list or dashboard to read, and the rule "renew anything expiring in the next 60 days".
- Quarterly privileged access review, every three months on the first Monday. Description: the groups to export, who signs off, and where the evidence goes.
- Quarterly licence and contract review, every three months on the 15th.
- Credential rotation, every 90 days from the date you set it up, assigned to the owner of the secret.
If a routine has several fixed steps owned by different people, use subtasks rather than one long description. See where checklist steps should live and Jira subtask template for the trade-offs.
Reporting on operations work #
Once requests, planned work and the routine are all in Jira, a few saved filters answer the questions an ops lead gets asked most:
- What routine work is overdue?
project = OPS AND labels = routine AND due < now() AND statusCategory != Done - Did every access review happen this year?
project = OPS AND summary ~ "access review" AND resolved >= startOfYear() - What is waiting on someone else?
project = OPS AND status = Waiting ORDER BY updated ASC
Replace OPS with your project key, and add the routine label to every recurring rule. Save each as a filter and subscribe to it, so the overdue list arrives by email every Monday. The Jira weekly report guide shows how to turn filters like these into a report your manager will actually read.
When the manual way is enough #
Not every ops team needs any of this. If you have a handful of routines and one person who owns them without fail, a calendar reminder and a cloned ticket are enough. If your team already runs Jira Automation rules comfortably inside your plan's usage, a Scheduled rule for the weekly backup check is the natural next step. A scheduling app earns its place when the routine list grows past what anyone wants to maintain as cron expressions, when holidays keep producing tickets on days nobody is in, or when an auditor wants proof that each cycle happened.
For a broader look at the options for repeating work, see Jira recurring tasks and Jira reminder.
Frequently asked questions #
Is Jira good for IT operations? Yes, for planned work and routine maintenance, and with Jira Service Management for requests and incidents. Keep the request queue and the planned work board separate so each is triaged the right way.
How do I track recurring maintenance in Jira? Make each routine a recurring ticket with a checklist, an owner and a due date. You can clone by hand, use a Jira Automation Scheduled rule, or use a scheduling app such as Recurring Work Items for Jira.
Can Jira create a ticket every Patch Tuesday? Yes. With Jira Automation you need a cron expression for "second Tuesday of the month". With Recurring Work Items for Jira you choose "second Tuesday" in the rule form, and set the due date as a few days after the run.