Blog ·
Jira tech debt: track it, size it, and pay it down on a schedule
Jira tech debt is easiest to manage when you treat it as two kinds of work. The first kind is a known shortcut with a known cost: a module nobody wants to touch, a test suite that takes forty minutes, a library three major versions behind. Those belong in Jira as ordinary work items, tagged so you can find them. The second kind is the routine that stops debt piling up in the first place: upgrading dependencies every month, reviewing the debt list every sprint, cleaning up feature flags every quarter. That second kind is work that comes back on a clock, and it is the part most teams never put in Jira at all.
This guide covers both. First how to record and find tech debt in Jira, then how to keep a share of every sprint for it, and then how to make the recurring paydown work create its own tickets.
A note on words. Jira Cloud now says spaces for projects and work items for issues in much of its interface. This article uses both.
How to track tech debt in Jira #
Jira has no built-in tech debt feature. You choose a way to mark it, and the choice decides how easy it is to report on later. There are three common options.
| Option | How it works | Good for | Watch out for |
|---|---|---|---|
| A label | Add tech-debt to any work item |
Teams that want zero setup | Spelling drift: techdebt, tech_debt, debt |
| A work type | Create a "Tech Debt" work type in the space | Teams that report on debt separately | Needs a space admin, and one more type on the create screen |
| A component | A Tech debt component per space |
Spaces that already use components well | Components are per space, so cross-space reports get harder |
Pick one and write it down. A label is the usual start because anyone can add it. If you go that way, make the label part of your work item template so nobody invents a second spelling. Our Jira task template guide covers ways to reuse the same fields every time.
Whichever you choose, give each debt item three things the rest of the backlog often lacks:
- The cost of leaving it. "Every release takes an extra hour because the build is not cached" is a reason to fix it. "Refactor the build" is not.
- Where it lives. A component, a service name or a file path, so the person who picks it up knows where to look.
- A rough size. Story points or a T-shirt size is enough. Debt with no size never gets planned.
JQL filters that keep tech debt visible #
A debt list that nobody looks at grows quietly. Save these filters once, and put the first two on a dashboard the team actually opens. Replace ABC with your space key, and labels = tech-debt with your work type or component if you chose one of those.
All open tech debt, oldest first:
project = ABC AND labels = tech-debt AND statusCategory != Done ORDER BY created ASC
Debt that has not been touched in three months:
project = ABC AND labels = tech-debt AND statusCategory != Done AND updated <= -90d
Debt fixed in the last sprint, which is the number worth showing in a review:
project = ABC AND labels = tech-debt AND statusCategory = Done AND resolved >= -14d
Debt with no size, the items that cannot be planned yet:
project = ABC AND labels = tech-debt AND statusCategory != Done AND "Story point estimate" is EMPTY
The field name in that last one depends on your space. Company-managed spaces often use "Story Points" instead.
Make room for it in every sprint #
The most common reason tech debt grows is that it always loses to features in planning. Two habits fix that more reliably than a heroic "debt sprint" once a year.
- Reserve a share of capacity. Agree on a fixed slice of each sprint, for example one item per developer or a set number of points, and fill it from the debt filter before features are pulled in. Our Jira capacity planning guide shows how to work out what the team can take on in the first place.
- Review the debt list on a rhythm. A short review every sprint or every two weeks: close what no longer matters, size what has no size, and move the three most expensive items to the top. A list that is reviewed stays honest. A list that is not turns into a graveyard.
The review only happens if somebody remembers to schedule it. That is the recurring part, and it is where the next section comes in.
The recurring tech debt routine #
Some debt work is not a one-off item at all. It comes back on a fixed cadence, and if nobody creates the ticket, it slips. Here is a routine that works for most software teams.
| Recurring work | Cadence | What the ticket holds |
|---|---|---|
| Tech debt review | Every two weeks, before planning | Link to the debt filter, a checklist: close, size, rank |
| Dependency upgrades | Monthly | Subtasks per repository or service |
| Security advisory check | Weekly | Link to your scanner's report, an owner |
| Feature flag cleanup | Quarterly | A list of flags older than a quarter to remove |
| Deprecated API sweep | Quarterly | Search for deprecated calls, one subtask per area |
| Test suite health | Monthly | Flaky tests to fix or delete, slowest tests to speed up |
Each one is small. Each one is easy to forget in a busy month. And each one is far cheaper done on time: a monthly dependency upgrade is a handful of minor versions, while a yearly one is a migration.
Create these tickets with Jira Automation #
Jira Automation can create a work item on a timer with its Scheduled trigger. 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 rule for the monthly dependency upgrade looks like this:
- Trigger: Scheduled, once a month.
- Action: Create work item in your space, type Task, label
tech-debt. - Summary: something like
Dependency upgrades {{now.format("MMMM yyyy")}}so each month's ticket has its own name. - Add subtasks with a second action, one per repository.
That works well for a handful of rules. It gets harder when the cadence is irregular (a review "the Thursday before every second Monday" cannot be said by a fixed interval, and some cadences cannot be said in cron at all) or when the rules count against a shared execution limit. Our Jira cron expression guide covers the syntax and its gaps, and Jira Cloud automation limits explains how scheduled rules are counted.
Create them with Recurring Work Items for Jira #
Recurring Work Items for Jira does one job: create the same work item on a schedule, inside one space. For the tech debt routine that means:
- A schedule chosen in a form. Daily, weekly on chosen days (every week or every few weeks), monthly on a date, or monthly on a weekday such as "the second Tuesday", every one, two, three or more months. A quarterly feature flag cleanup is "every 3 months on the first Monday".
- Titles that name their period. Write
Dependency upgrades {{now.monthName}} {{now.year}}and each ticket gets its own title. The full list is on the tokens page. - A due date set for you. Use a date a few days after the run, so the upgrade ticket arrives with its deadline already on it.
- Subtasks every time. One per repository, created with the parent.
- Working days respected. A run that falls on a weekend or a listed holiday can be moved or skipped instead of landing when nobody is in.
- A preview before saving. The editor shows the next five dates, so you can check "the first Monday every three months" means what you think.
- A run history. Every run says whether it created the work item, skipped or failed, and why.
If you already have Automation rules doing this, the app can import Automation's own export file and report what it can carry over before it writes anything.
When the manual way is enough #
You do not need any automation if:
- Your team is small and one person already runs planning and remembers the review.
- You have one or two recurring debt tasks, and a calendar reminder works.
- Your debt is mostly one-off items, and the capacity rule above is all you need.
Automate the recurring part when it has started to slip, or when the routine has grown past what one person can hold in their head. The first sign is usually a dependency upgrade that turned into a two-week migration because nobody did the monthly one.
A starting setup for this week #
If you want something to do today:
- Pick a label, a work type or a component for tech debt, and write the choice in your space's description.
- Save the four filters above, and put the first two on the team dashboard.
- Agree on a fixed share of each sprint for debt.
- Create the recurring review and the monthly dependency upgrade, by Automation or with Recurring Work Items for Jira.
- After a month, look at the "fixed in the last sprint" filter. If the number is zero, the share was not protected in planning, and that is the conversation to have.
For the wider routine that keeps a space trustworthy, our Jira hygiene guide lists the cleanup checks, and groomed backlog covers what a backlog ready for planning looks like.
Frequently asked questions #
Should tech debt be a separate Jira project? Usually not. Debt lives next to the code it belongs to, so it should sit in the same space as the feature work and compete for the same sprints. A separate space tends to become a place where debt is filed and forgotten.
Is tech debt a bug? No. A bug is behaviour that is wrong today. Tech debt is a shortcut that makes future work slower or riskier. Keeping them apart makes both easier to report on.
How much of a sprint should go to tech debt? There is no single right number. Pick a share your team can protect every sprint, measure how much gets done with the filters above, and adjust after a few sprints.
Can Jira create a tech debt review ticket every two weeks? Yes. With Jira Automation, use the Scheduled trigger at a fixed rate of 14 days. With Recurring Work Items for Jira, choose weekly, every two weeks, on the day before planning.