# Use Time Tracking fields

## 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.

<figure><img src="https://214285790-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSkiYngzIxDvQc4NgdNa6%2Fuploads%2FYj5G6zvccBQVjCajUTHf%2Fimage.png?alt=media&#x26;token=bdc7ab73-d44a-42eb-ba7f-e468de76507f" alt="Dev Time and QA Time fields displayed side by side on a single Jira issue"><figcaption><p>Dev Time and QA Time on one issue</p></figcaption></figure>

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 minutes
* `2h` — 2 hours
* `1d 3h` — 1 day and 3 hours
* `2w 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

1. Find the field (e.g. "QA Estimate" or "SLA Budget").
2. Enter the initial estimate (for example `4h` or `1d 2h`).
3. 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 `3h` to `5h`).
* **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.

<figure><img src="https://214285790-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSkiYngzIxDvQc4NgdNa6%2Fuploads%2Fq72H45uMWsfd1jHTq3G2%2Fimage.png?alt=media&#x26;token=2a32c111-f3d0-463a-9caf-4aec34ceb610" alt="Modal dialog for logging time on the Dev Time field" width="377"><figcaption><p>Logging time on Dev Time field</p></figcaption></figure>

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.

{% content-ref url="../configuration/multiple-time-tracking-fields-on-one-issue" %}
[multiple-time-tracking-fields-on-one-issue](https://teranoapps.gitbook.io/time-tracking-custom-field/configuration/multiple-time-tracking-fields-on-one-issue)
{% endcontent-ref %}

***

## Search, 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.

<figure><img src="https://214285790-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSkiYngzIxDvQc4NgdNa6%2Fuploads%2FZfRnwkhq3jC6sVjwkyXE%2Fimage.png?alt=media&#x26;token=2864d463-46ce-4cfc-9b55-185525bc3a4a" alt="JQL query using a Dev Time field alias"><figcaption><p>Using Dev Time field in JQL query</p></figcaption></figure>

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](https://teranoapps.gitbook.io/time-tracking-custom-field/search-and-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**.

{% hint style="info" %}
**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.
{% endhint %}
