Jira Multiple Time Tracking Fields: Separate Dev, QA, SLA and Contract Time on One Issue

Jira only has one time tracking field. What if your team needs more?

If you’ve ever typed something like “Jira multiple time tracking fields”, “separate Dev and QA time in Jira” or “billable vs non-billable time in Jira” into Google, you’ve already hit one of Jira’s oldest limitations: it only really understands one time budget per issue.

Out of the box you get a single Time Tracking field with three numbers behind it: Original Estimate, Remaining Estimate and Time Spent. That’s fine when “time on this issue” is one number. It breaks down completely when you need separate buckets for Dev, QA, SLA, contract work, or billable vs internal time.

This post is about that exact problem – and about what happens if you give each team its own Jira-style time tracking field on the issue.

Where Jira’s built-in time tracking runs out of road

Jira’s standard model is simple: you estimate once, you log work into one place, you watch Remaining tick down. For many teams that’s enough. But real projects rarely look that clean.

Jira’s single time tracking field — but where do Dev, QA, and SLA time go?

You might want to know, for a single issue:

• How many hours went into development vs testing.

• How much time was spent on contract billable work vs internal coordination.

• How much of your SLA budget is already used on this ticket.

Now imagine trying to cram all of that into one time tracking field. You either stop tracking some of those dimensions, or you start inventing workarounds with labels, comments and spreadsheets.

Jira supports only a single time tracking field per issue, which makes it difficult to separate Dev, QA, SLA or contract work.

If you need multiple Jira-style time tracking fields on the same issue, you can use Time Tracking Fields for Jira — a Forge app that adds additional Time Tracking fields.

The usual workarounds (and why they hurt)

Most teams start by hacking the tools they already have. You’ve probably seen at least one of these patterns.

Some teams add plain custom fields – simple numbers like “QA hours” or “Billable hours” – and ask people to maintain them manually alongside the main time tracking. You quickly end up with drift: Time Spent says one thing, custom fields say another, and nobody is sure which number is real.

Others go even rougher: they log all work into the standard time tracking field, and then annotate worklog comments with tags such as “[DEV]”, “[QA]”, “[BILLABLE]”. Reporting then happens in Excel, after exporting everything and trying to parse those tags. It works, but only if someone is dedicated to being the spreadsheet magician.

Jira fields, spreadsheets, tagged worklogs — three time sources, zero single source of truth.

There are also teams who simply give up on Jira for detailed time analysis and move their time tracking to a separate tool or database. That solves reporting, but creates a disconnect: your issues live in Jira, your time lives elsewhere.

All of these approaches share the same problems: they’re fragile, they don’t feel native, and they don’t integrate well with JQL, dashboards or automation.

What if you had multiple Jira-style time tracking fields on the issue?

Now flip the model.

Instead of one global time tracking field per issue, imagine that you can add multiple fields of type “Time Tracking”, and each one behaves exactly like the native Jira field:

• each field has its own Original, Time Spent, and Remaining,

• each shows a familiar progress bar on the issue,

• each has its own Jira-style “Log work” dialog with duration formats like 1w 2d 3h,

• each can participate in JQL, dashboards, and automation rules.

Separate Dev and QA time, each with its own Jira-style tracker.

On a single issue you might see:

• Dev Time – the development estimate, time spent and remaining for the engineering team,

• QA Time – the time budget just for testing,

• SLA Time – the contractual time budget for support,

• Contract Hours – the hours that a client will actually see on an invoice.

Everyone still uses the Jira UI they already know. They just log into the bucket that matches their work.

Real-world scenarios where this makes a difference

Consider a product team that wants to untangle development and testing.

Developers estimate and log into Dev Time. They see their own Original Estimate, Remaining and Time Spent. Testers do the same in QA Time. At any point you can glance at an issue and see whether Dev is done while QA still has an untouched estimate, instead of guessing from a single mixed number.

Another common pattern is separating billable and non-billable time. You might create fields like Contract Hours and Internal Time. Contract Hours is what you report to the client and base invoices on. Internal Time is where you track analysis, meetings and experiments that are important for your own planning but shouldn’t appear on the customer’s bill. Both live on the same issue. Both behave like first-class Jira time tracking fields.

Dashboards powered by separate Dev, QA and SLA time buckets.

For support or maintenance teams, an extra field like SLA Time is hugely valuable. You can load it with a specific time budget based on the client’s contract, then log only SLA-relevant work into that field. When the remaining SLA budget drops under a threshold, Jira automation can warn the team, add a comment or escalate the issue, while the rest of the work on the ticket keeps its own timeline.

Search, dashboards and automation when time fields are first-class

The real power of multiple time tracking fields isn’t just seeing them on the issue. It’s what happens when they behave like native Jira time fields everywhere else.

In JQL, you can filter on each field’s properties. For example, you might search for issues where QA Time still has remaining work while Dev Time is already burned down, or pull a list of tickets where SLA Time has gone over its original estimate. You’re not parsing comments or guessing from generic numbers; you’re querying real, structured time data.

On dashboards, you can put Dev Time and QA Time into gadgets as separate columns, build statistics on SLA Time remaining per project, or create views tailored to each team. A QA lead might live in a dashboard that only cares about QA Time. A project manager might focus on Contract Hours.

With automation, you can wire rules directly to these custom time tracking fields. When QA Remaining falls below one hour, a comment can be added automatically or the status can change. When SLA Time is overspent, you can label the issue for follow-up before the next invoice. Because these are proper time tracking fields, the rules can react to the same kind of signals you’re used to from the built-in time tracking.

How my Marketplace app fits into this idea

Everything above is the design principle behind our Jira app on Atlassian Marketplace:

Add multiple time tracking fields per issue for separate QA, SLA, and contract estimates.

The app lets you log time into separate buckets so each team gets its own Jira-style time tracking field on the issue. Developers log work into Dev Time, QA into QA Time, support into SLA Time. Each bucket has its own original, remaining and spent time, plus the usual progress bar and duration formats your team already knows.

Those custom time tracking fields behave as first-class citizens in Jira search, dashboards and automation. You can filter by Dev Time remaining, build dashboards that compare Dev and QA estimates, and trigger alerts when QA or SLA time is running out, without external databases or scripts.

From an admin perspective, configuration is familiar. You create a new custom field of type Time Tracking, add it to the relevant screens, and tune hours-per-day and days-per-week so each extra time bucket behaves just like a built-in Jira field. Under the hood it’s built on Atlassian Forge, which keeps data inside the Atlassian ecosystem and avoids extra infrastructure.

Native setup: Dev, QA and SLA time fields configured like any other Jira custom field.

For small teams, there’s a free tier up to ten users, plus a trial period and a short setup path so you can test the idea without redesigning your entire process.

Closing thoughts

If you’re constantly fighting Jira’s single time tracking field, it’s not because you’re using the tool “wrong”. It’s because many teams genuinely need multiple independent time budgets on a single issue.

Whether you build your own solution on top of custom time tracking fields or use an app that does the heavy lifting for you, the shift from “one time field per issue” to “multiple Jira-style time buckets” can completely change how clearly you see Dev vs QA, billable vs internal, or planned vs contractual time in your projects.

If you want to try this approach in your own Jira, you can install Time Tracking Fields for Jira from the Atlassian Marketplace.