How to add a custom time tracking or duration field in Jira Cloud (Jira & JSM)

[#1]

A QA estimate that doesn't overwrite the developer's estimate. An SLA limit of 4h stored on the request so an automation rule can compare against it. A baseline estimate, frozen at sprint start, sitting next to the one the team keeps revising. Three different needs, one shared requirement: a field that holds an amount of time. All three run into the same wall, and some version of the question — "can I create a second time tracking field?", "is there a duration field type?" — has been on this Community since at least 2017.

This article maps where Jira Cloud stands in 2026: what the native Time Tracking module covers, what formula fields changed (and what they didn't), where the number and text workarounds break, and what's left when none of that fits. Written for Jira admins and delivery leads who own field configuration.

Native Jira gives you one time tracking module per work item; separate fields per kind of effort are a different thing entirely.

Why you can't just create a second one

Time tracking in Jira Cloud isn't a field type — it's a module. Original estimate, remaining estimate, time spent and the worklogs behind them are wired into the work item itself, and the Time tracking entry you see in the fields list is locked: it exists once, and there's no "create another" behind it.

The proof is in the field-type picker. Open Jira Settings → Work items → Fields → Create new field and read what an admin can actually create: text and number fields, dates, select lists and pickers, formula fields, and a handful of information-display fields that report something Jira already knows — Time in status, Days since last comment, Date of first response. The entries that touch time either store a point in time (date picker, date time picker) or report a span Jira measured for you. None of them stores a length of time somebody types in — and the closest numeric option, the Number field, offers three formats: number, currency, percentage.

Both gaps have open feature requests, and both are old: JRACLOUD-94778 ("Ability to add a Time/Duration Custom Field") was raised in April 2017 and has 412 votes; JRACLOUD-67720 ("Duration Custom Field Type") followed six months later. Both are still Gathering Interest.

The shape of the problem isn't unique to time. Jira Cloud gives every work item one attachment area and no attachment field type either, which sends admins through the same round of workarounds — that gap is mapped in an earlier article on attachment custom fields.

So, plainly: as of August 2026, out of the box Jira Cloud has exactly one time tracking module per work item and no custom field type a user can type a duration into — the newest native option, the formula field, can display a duration but not capture one.

What you can do natively

The native Time Tracking module — genuinely the answer, for one estimate

If your team needs one estimate per work item and wants to log work against it, stop here: native time tracking does the whole job, and no app is needed. Original estimate, remaining, time spent, worklogs with dates and authors, the built-in time tracking report — and real JQL, since originalEstimate, remainingEstimate, timeSpent and workRatio all work in filters, dashboards and automation rules.

Two limits. There is exactly one of it, so "the same, but for QA" isn't a configuration option — it's the reason this article exists. And team-managed projects expose a single estimation setting, so the choice is which unit you estimate in, not how many estimates you keep.

Formula fields — read the fine print, it matters

This is what changed recently, and it's the option most likely to be suggested to you in a thread. Formula fields were announced in December 2025, reached team-managed spaces first and company-managed ones after that, work in JQL search and automation rules, and the documentation lists duration among the output formats. On the surface that reads like "Jira Cloud has a duration field now". It doesn't — and the docs are refreshingly direct about why: formula fields "calculate values but can't be edited directly". There is no input, and a formula's scope is a single work item.

So the honest split: if the duration you need is derived — turnaround from two date fields, a remaining budget from two numbers — a formula field is the native answer, and a good one that didn't exist a year ago. If a human has to type 2h 30m, it's the wrong tool, because there's nowhere to type. The same goes for automation rules that compute a duration into a text or number field: fine for what Jira can work out by itself, no help when the value lives in someone's head.

Number and text fields — the usual workaround, and the first to rot

Create Dev Hours and QA Hours as Number fields, ask people to type 3.5, and you can sort and sum immediately — the fastest setup on this list. It also has no duration format and no validation, so 1.5 is hours to one person and something else to the next, 1h 30m isn't accepted at all, and nothing ties the number to worklogs: it's a figure someone updates by hand, drifting away from the record of what actually happened. A Short text field inverts the trade — 2h 30m renders exactly right, then sorts alphabetically, can't be aggregated, and reduces JQL to substring matching, where ~ "2h" also matches 12h.

Subtasks per phase — a real structure, at a price

Give each phase its own subtask and its own native time tracking and you get separate estimates that roll up to the parent. Plenty of teams run it. The price: your hierarchy now encodes a reporting decision that boards, filters and hierarchy reports all inherit, and "QA time last quarter" depends on everyone naming subtasks consistently for a quarter.

Worklog-categorisation apps — a different model

Worth naming as a category, because it solves an adjacent problem well: instead of separate fields, these apps categorise worklogs — by account, work category or similar — and report across them. If your question is "how much time went to this client across every project", that fits better than fields. If you need the time to be a field on the work item — on screens, in JQL, checkable by a validator — it doesn't, because that's not where the value lives.

The scorecard so far:

What you need	Native option	What it actually gives you
One estimate plus logged work	Native Time Tracking module	Everything: estimate, spent, remaining, worklogs, JQL, reports
A second, independent estimate (QA, vendor, baseline)	—	Nothing
A duration a person types in (4h SLA limit)	—	Nothing
A duration calculated from other fields	Formula field, duration output	Display and automation — read-only, one work item at a time
A rough number of hours	Number field	A number, with no duration format and no link to worklogs
Time split by phase	Subtasks with native time tracking	Works, if you're willing to spend hierarchy on it

The short version: what each native option can and can't hold.

Where native stops, and what a field type changes

Every gap above traces back to one fact: time isn't a field type in Jira Cloud. So the fix is to add the type. Full disclosure: we build Time Tracking Fields for Jira at Terano Apps, and the steps below use it. It registers two custom field types — Time tracking and Duration — which is the whole idea: once "time" is a type, everything after it is ordinary Jira administration.

Step 1 — Create a Time tracking field for each kind of effort

Go to Jira Settings → Work items → Fields, choose Create new field, and pick Time tracking as the type. Name it for the effort it holds — QA Time, Dev Time, Vendor Hours — and add it to the create, edit and view screens of the relevant work item types.

Jira's own Time tracking field is locked and exists once; the Time tracking field type in the Create field dialog on the right can be created as often as you need.

Step 2 — Log work against each field independently

Each field carries its own original estimate, logged time and remaining time, and behaves the way people already expect: log an hour and remaining drops by an hour. Because each field owns its worklogs, "how much QA went into this?" and "how much dev?" become two separate, answerable questions on one work item — no subtasks involved.

A Time tracking field on a work item — "QA Time", 2h logged and 1d remaining, with its own progress bar.

Step 3 — Use a Duration field where there's nothing to log

Not every time value is work. An SLA limit, a meeting length, a response window — these are single numbers nobody logs hours against. That's the Duration type: created the same way, it stores one value in the same Jira-style format and normalises it on save, so 90m settles as 1h 30m. Longer values follow the field's own hours-per-day and days-per-week settings: with an eight-hour day, 10h settles as 1d 2h. It goes on screens like any other field, including a request form in Jira Service Management, so the value can be captured straight from the portal.

A Duration field on a work item, holding an SLA time of 2d 3h — one value, no worklogs attached.

Step 4 — Keep your existing reports working

The usual objection here is fair: native reports, dashboards and integrations read native time tracking, and time living in custom fields isn't in there. So configure a bucket set in the project — pick the fields that belong together, and native Time tracking is kept in sync with their combined totals. Spent and remaining roll up, existing reports keep working, and the per-field detail stays available underneath.

The rollup as it looks on the work item: QA Time (2h logged, 1d remaining) and Dev time (3h, 2d) feed Jira's native Time tracking above them — 5h logged, 3d remaining, the sum of both.

Make it queryable

A time value you can't query is a note. Each field exposes JQL aliases: a Time tracking field publishes OriginalEstimateSeconds, TimeSpentSeconds and RemainingEstimateSeconds, plus formatted string counterparts; a Duration field publishes DurationSeconds and Duration.

"QA Time.RemainingEstimateSeconds" < 3600 AND statusCategory != Done

"SLA Time.DurationSeconds" > 14400

"Dev Time.TimeSpentSeconds" > 0 AND "QA Time.TimeSpentSeconds" = 0

The first finds work items nearly out of QA budget, the second flags SLA limits above four hours, the third finds work that was developed but never tested. Save any of them as a filter and it becomes a dashboard gadget; drop the same JQL into a rule as a condition and it becomes a notification.

A custom Time tracking field queried directly in JQL: "QA Time.TimeSpent" resolves like any other indexed field, and the field renders its own value in the results column.

Where this lands in practice

• Engineering — Dev Time and QA Time as separate fields, so a testing overrun stays visible instead of disappearing into one shared estimate.
• Service management — an SLA Time Duration field on the request, so the threshold lives on the work item and a rule can compare against it, rather than being hard-coded in the rule.
• Contract and agency work — Contract Hours tracked apart from internal effort, with a saved filter listing every work item whose remaining budget has hit zero.

Quick answers

Can you have two time tracking fields on one work item in Jira Cloud?
Not natively — the native Time tracking module exists once per work item and can't be instantiated again. Separate estimates natively means separate subtasks, or a custom field type that provides time tracking as a type.

Is there a duration custom field type in Jira Cloud?
No. The types an admin can create include number, text, date, formula and the information-display fields, but nothing that stores a duration you enter. JRACLOUD-67720 has been open since 2017.

Can a formula field store a duration?
It can display one — duration is a supported output format — but formula fields calculate their values and can't be edited directly, so nobody can type a duration into one. The calculated result is searchable in JQL and usable in rules — the limit is input, not reporting. They fit derived values, not entered ones.

Can you query custom time tracking fields in JQL?
Native JQL covers native time tracking through originalEstimate, timeSpent, remainingEstimate and workRatio. Custom time fields need to expose their own aliases to be searchable — worth checking before you commit to any approach, because a time field JQL can't see can't power a filter, a dashboard, or a rule.

Try it

Time Tracking Fields for Jira is available on the Atlassian Marketplace:

→ Time Tracking Fields for Jira

If you've solved multiple estimates a different way — subtasks, worklog categories, a formula field doing something clever — I'd genuinely like to read it in the comments. This is one of those problems where the workaround people settle on says a lot about how their team plans.

Michał Krysiuk, Terano Apps