Use Time Tracking fields
This page explains what a Time Tracking field is and how to use it in everyday work — entering estimates, logging time, and tracking remaining effort.
What a Time Tracking field is
In Jira Cloud there is only one built-in Time Tracking module per issue (original estimate, remaining estimate, time spent). You can configure it globally, but you cannot create a second native Time Tracking field for things like QA, SLA, or contract budgets.
Time Tracking Customfield introduces a new custom field type that behaves like Time Tracking but can be created multiple times:
Each field you create (for example "QA Estimate", "SLA Budget", "Contract Hours") is an independent instance of this type.
All these fields follow the same general interaction model as Jira's own Time Tracking, so users don't have to learn a new concept.
You can attach different instances to different projects, screens, and workflows, depending on what each team needs.
You can think of it as "extra Time Tracking fields" you can create on demand.
Original, remaining, and spent — same model, more buckets
Time Tracking fields use the same mental model as Jira's original Time Tracking:
Original estimate — initial planned effort.
Remaining estimate — effort still left.
Time spent — already logged work.
The difference is that each custom field instance keeps its own trio:
A QA field might track original QA estimate, remaining QA time, and QA time spent.
An SLA field might track original SLA budget, remaining SLA time, and SLA time used.
On a single issue you can therefore have, for example:
The global Jira Time Tracking for overall effort.
A Time Tracking field for QA effort.
Another Time Tracking field for contract / support budget.
Each is a separate bucket of time with its own original / remaining / spent values.
Where you see the field
Depending on configuration, you may see one or more Time Tracking fields:
On the Create Issue screen — to enter an initial estimate for that dimension (e.g. QA).
On the issue view / edit screen — usually near other estimate fields, often with a small progress display.
On transition screens — if the admin added the field there (e.g. when moving to "In QA" or "Done").
On customer portals — if the field is exposed to request forms in Jira Service Management.
If you don't see it on a given project or issue type, it usually means it hasn't been added to those screens. Ask your Jira admin to check.
Entering and updating time
You use Time Tracking fields the same way you already use Jira time tracking.
Duration format
Enter time using Jira-style duration strings:
30m— 30 minutes2h— 2 hours1d 3h— 1 day and 3 hours2w 1d— 2 weeks and 1 day
You can mix units (1d 4h 30m). Whether a plain number like 120 means minutes or hours is decided by your admin, but it's consistent for everyone for that field.
If the value can't be interpreted as a duration, the field will show an error and ask you to correct it.
When creating an issue
Find the field (e.g. "QA Estimate" or "SLA Budget").
Enter the initial estimate (for example
4hor1d 2h).Create the issue.
The field treats this as its original estimate and sets remaining time accordingly, just like the native Time Tracking does.
On existing issues
On an existing issue you can:
Edit the estimate directly — inline or via the edit screen, by simply changing the value (e.g. from
3hto5h).Log work through the field's editor — if your admin enabled the more advanced view with a modal:
Enter time spent (e.g.
1h) and optionally adjust remaining time.Save; the field increases spent and adjusts remaining, mirroring Jira's behaviour.
From your point of view, it works like logging and adjusting time in the regular Time Tracking — just on a different field.
Multiple time tracking fields on one issue
Your team can have several Time Tracking fields side by side, for example:
Dev Estimate — time for implementation.
QA Estimate — time for testing.
SLA Hours — time allowed under a support contract.
How to think about it as a user:
Each field is a separate dimension of time.
Log your work against the field that matches what you're doing (dev vs QA vs support).
When reading an issue, look at each field independently — dev might be on track while SLA is nearly exhausted.
If you're ever unsure which field to use, follow your team's naming conventions or ask your project owner.
Multiple time tracking fields on one issueSearch, reporting, and dashboards
You don't need to know implementation details to benefit from reporting, but a few points are useful:
Time Tracking fields store durations in a consistent numeric form (seconds) in addition to the human string.
This makes them safe to use in JQL filters, dashboards, automation, and exports.
Admins can:
Filter by thresholds ("remaining QA estimate > 4h").
Build dashboards around specific custom time buckets.
Use these fields in automation rules and CSV exports.
If your admin includes these fields in filters, gadgets, or boards, the values you enter will show up there just as reliably as native Time Tracking.
For the full list of aliases and JQL examples, see Search & Reporting.
Working alongside native Time Tracking
Time Tracking fields do not replace Jira's standard Time Tracking — they extend it.
You keep using the native Time Tracking for your main, global effort tracking. On top of that, your admin can add * extra Time Tracking fields* wherever separate time buckets are needed (QA, SLA, contract, baseline, etc.).
Because the app uses the same underlying Jira context and permissions:
Permissions work as usual (if you can edit the issue, you can edit the field, unless the admin made it read-only).
Fields can be added/removed from screens without breaking global time tracking.
Native Time Tracking and custom Time Tracking fields can live on the same issue without conflict.
In short: Time Tracking fields work just like Jira's Time Tracking — but you can have as many separate fields as your teams need (Dev, QA, SLA, contract, etc.). Each field follows the same rules for entering and updating time ( original, spent, remaining), so you only choose which time bucket you're logging to.
Last updated