How to Track Time Off in Jira Without Creating 200 Issues

A 50-person team takes roughly 200 days of PTO per year. If each day off becomes a Jira issue, your backlog now has 200 tickets that have nothing to do with the actual work your team ships. Multiply that by a few years, add sick days and half-days, and you are looking at thousands of issues clogging your project.

And yet, tracking time off matters. Sprint planning falls apart when you do not know who is available. Managers need a way to approve requests. Finance needs data for accrual reporting. Someone, somewhere, needs to know how many vacation days each person has left.

The question is not whether to track time off. The question is how to do it inside Jira without making a mess of your board.

Approach 1: One Jira issue per absence

The simplest approach. Someone takes three days off, they create a Jira issue titled "PTO - June 10-12." The manager moves it to Approved. When the days pass, it gets moved to Done.

What works: It is easy to set up. No configuration required. Managers can filter the board by issue type to see upcoming absences.

What breaks: At scale, this floods the project. Sprint boards become a mix of real work and PTO tickets. There is no balance tracking. If you want to know how many days someone has left this year, you have to manually count resolved issues. JQL queries can approximate it, but they are fragile and do not account for half-days, multi-day spans, or different leave types.

Verdict: Works for teams under 10 who do not need balance tracking. Falls apart past that.

Approach 2: Jira automation rules

You build automation rules to handle the workflow: auto-assign approvals, send Slack notifications when someone is out, auto-close tickets after the leave dates pass. Some teams use custom fields for start date, end date, and leave type, then build dashboard gadgets to report on them.

What works: It removes some manual steps. Approval routing can be automated. Calendar views (with third-party gadgets) can display absences.

What breaks: Automation rules need maintenance. When someone changes the leave type options, or you add a new team, the rules need updating. Balance tracking still requires manual calculation or a ScriptRunner script. Holiday detection (is the requested day a public holiday?) requires hardcoding holiday lists and updating them annually. Cross-timezone teams make this even more complex.

Verdict: A significant investment in configuration for a partial solution. If you have a Jira admin with time to spare, it can work. Most teams do not.

Approach 3: Spreadsheet alongside Jira

HR maintains a Google Sheet or Excel file with everyone's balances. Leave requests come in through Slack or email. HR updates the spreadsheet. Jira is not involved at all, or a single issue links to the spreadsheet for reference.

What works: Spreadsheets are flexible. They handle balance calculations, different leave types, and country-specific rules easily. Every HR person already knows how to use them.

What breaks: The data lives outside your system of record. Managers cannot see who is out from within Jira. Sprint planning requires checking a separate tool. There is no approval workflow, just an email thread. When the spreadsheet owner goes on vacation (irony intended), updates stop.

Verdict: This is what most teams actually do, and it is fine until you hit about 30 people. After that, the manual overhead becomes a part-time job. For a deeper comparison of Jira-native vs. external HR tools, see the full comparison page.

Approach 4: A purpose-built leave layer inside Jira

Instead of bending Jira's issue model to handle leave, you add a dedicated leave management system that runs inside Jira. Leave requests, balances, approvals, and team calendars exist in their own data model, separate from your project issues.

What works: Leave data does not pollute your backlog. Balances are computed automatically based on accrual rules and approved requests. Holiday calendars are built in (with country-specific support). Managers approve requests from within Jira. Team availability is visible during sprint planning.

What breaks: You need to install and configure an app. There is a small onboarding cost.

What to look for in a Jira leave-tracking app

If you go with Approach 4, not all Marketplace apps are equal. The things that matter most:

• Balance calculation. The app should compute remaining days automatically based on approved requests, accrual rate, and carry-over policy. You should not have to enter balances manually.
• Holiday awareness. Public holidays vary by country. If your team spans the US, UK, and India, the app should know that July 4th is only a holiday for your US employees.
• Leave types. Vacation, sick leave, personal days, parental leave, bereavement. Each type may have a different balance and different approval rules.
• Team visibility. A calendar or dashboard showing who is out this week. This is the feature that makes capacity planning possible.
• Data residency. If you are running Jira Cloud, your leave data should stay on Atlassian infrastructure. Check whether the app is Forge-native (data stays in Atlassian) or Connect-based (data may be stored on external servers).

The TeamOps approach

TeamOps takes Approach 4. Leave requests live in their own data model, not as Jira issues. Balances are computed on the fly from approved requests and your configured accrual policy. Multi-country holiday detection is built in for six countries, with support for adding custom holidays.

Your sprint board stays clean. Your leave data stays inside Atlassian. Your managers see a team availability view without leaving Jira.