Overview

Time Tracking Customfield is a Jira Cloud app that introduces a time-tracking custom field type. It behaves like Jira’s built-in Time Tracking field, with one crucial difference: you can create as many separate time tracking fields as you need.

In standard Jira Cloud, the native Time Tracking module (original estimate, remaining estimate, time spent) exists only once per issue and cannot be added as an ordinary custom field type. If a team needs more than one time-based estimate, Jira provides no native way to do it.

Time Tracking Customfield closes this gap by giving you a new custom field type for durations that:

  • Follows the same behaviour and user expectations as Jira’s original Time Tracking field.

  • Can be created multiple times and reused across projects, screens, and workflows.

  • Stores and indexes values in a way that supports reliable JQL, dashboards, exports, and automation, not just display.

Why this app exists

For years, Jira Cloud customers have been asking Atlassian for a duration or time-tracking custom field that works like the built-in one. Public feature requests such as JRACLOUD-94778 and JRACLOUD-67720 have been open since 2017, and there are multiple related discussions on Atlassian Community where teams describe exactly this need.

Because these requests remain unresolved on the Jira Cloud platform, many teams are forced into workarounds:

  • Using generic text or number fields for time values.

  • Maintaining custom scripts or marketplace add-ons just to parse and validate durations.

  • Accepting that search, reporting, and automation over those fields will be fragile or limited.

Time Tracking Custom Field was created specifically to offer a clean, Jira solution to this long-standing problem.

What the app adds to Jira

Time Tracking Custom Field introduces a custom field type that behaves like Time Tracking but can be instantiated multiple times:

  • You can create any number of independent time tracking fields, each with its own name and context (for example, “QA Estimate”, “SLA Budget”, “Contract Hours”, “Baseline Estimate”).

  • Each field follows the same interaction model users already know from Jira’s original Time Tracking: duration input, consistent formatting, and Jira-style behaviour on issues.

  • Values are stored in a way that supports:

    • Consistent display across Jira (issue view, navigator, exports).

    • Full participation in JQL, dashboards, automation rules, and CSV exports.

Instead of treating durations like anonymous text, this field type is semantically aware of time, just like the native Time Tracking module.

Typical use cases

Teams use Time Tracking Custom Field when they need more than one meaningful duration per issue, for example:

  • A separate QA/testing estimate alongside the main development estimate.

  • An SLA timer, representing the contracted time limit for a customer request.

  • A contract budget field that tracks hours against a commercial agreement.

  • A baseline or initial estimate that must remain fixed, even if the main estimate changes over time.

In all of these cases, the goal is the same: keep the familiar Jira-style experience, but apply it to multiple, clearly named time tracking fields instead of only one global Time Tracking module.

Who the app is for

Time Tracking Custom Field is designed for:

  • Product and engineering teams that require multiple estimates per issue (e.g., development vs QA vs external vendor).

  • Support and service teams that work with SLAs, response or resolution budgets, and contract hours.

  • Project managers and delivery leads who need strong reporting on different types of time within the same project.

  • Jira Cloud administrators who want a configurable, Forge-based solution that:

    • Respects Jira permissions and security models.

    • Integrates with existing screens, workflows, and request types.

    • Avoids maintaining custom scripts or external storage.

How it fits into Jira Cloud

From an admin perspective, Time Tracking Custom Field behaves like any other Jira custom field type:

  • You create a new field of type “Time Tracking” in Jira’s custom fields administration.

  • You add it to screens, screen schemes, workflows, and service project portals, just like any other custom field.

  • You use it in JQL, dashboards, automation conditions/actions, and exports.

From an end-user perspective, the field feels like a natural part of Jira:

  • The interaction model is aligned with the existing Time Tracking behaviour, so there is very little training needed.

  • Users immediately recognise that they are working with a time-tracking field, not generic text.

  • Multiple time-tracking fields can coexist on the same issue, each with a clear purpose and label.

In short, Time Tracking Custom Field gives you the missing building block that Jira Cloud has not yet introduced natively: a reusable, Jira-style time tracking custom field type you can use wherever your teams need it.

NextProduct Tour

Last updated