Overview
Time Tracking Customfield is a Jira Cloud app that gives you reusable, duration-aware custom field types — a full Time Tracking field and a simpler Duration field.
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 — or even a single, simple duration value — Jira provides no native way to do it.
Time Tracking Customfield closes this gap by giving you two new custom field types for durations that:
Follow 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.
Store and index 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 Customfield was created specifically to offer a clean, Jira-native solution to this long-standing problem.
Two field types, one app
The app provides two custom field types to cover different needs:
A full time tracking field with three values: original estimate, time spent, and remaining estimate.
Log work against an estimate and track how much time is left.
Remaining time adjusts automatically as you log work — just like Jira's built-in Time Tracking.
Exposes six JQL aliases (
OriginalEstimateSeconds,TimeSpentSeconds,RemainingEstimateSecondsand their string counterparts).
Best for: development estimates, QA budgets, contract hours — any scenario where you need to track effort over time.
A single-value duration field — simpler to set up and use.
Store one time value directly (e.g.
4h,2w 1d).No work-logging workflow — just enter or update the value.
Exposes two JQL aliases (
DurationSeconds,Duration).
Best for: SLA limits, meeting durations, time budgets, one-off thresholds — any scenario where you just need to record a duration.
Both field types share the same duration format (2w 1d 3h 4m), the same configurable time units (hours per day, days per week), and the same JQL / reporting capabilities.
Not sure which to pick? If you need to log work and track remaining time, choose Time Tracking. If you just need to store a duration value, choose Duration.
Typical use cases
Use the Time Tracking field when you need to track work over time:
A separate QA/testing estimate alongside the main development estimate.
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.
Multiple team-specific effort trackers on the same issue (Dev, QA, Support).
Use the Duration field when you need a simple time value:
An SLA response or resolution time limit for customer requests.
A meeting or event duration attached to an issue.
A one-time time budget without work logging (e.g. "max 4h for this task").
A time-based threshold used in workflow conditions or automation rules.
In all of these cases, the goal is the same: keep the familiar Jira-style experience with properly indexed, searchable time data — instead of relying on plain text or number fields.
Who the app is for
Time Tracking Customfield 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 and workflows, and avoids maintaining custom scripts or external storage.
How it fits into Jira Cloud
For admins
Both field types behave like any other Jira custom field type:
Create a new field of type Time Tracking or Duration in custom fields administration.
Add it to screens, screen schemes, workflows, and service project portals.
Use it in JQL, dashboards, automation conditions/actions, and exports.
For end users
The fields feel like a natural part of Jira:
The interaction model aligns with existing Time Tracking behaviour — very little training needed.
Users immediately recognise they are working with a time-aware field, not generic text.
Multiple fields of either type can coexist on the same issue, each with a clear purpose and label.
Next steps
Product TourGetting StartedConfigurationUse Cases & Best PracticesUser GuideLast updated