To log time in Jira: open the issue → click Log Work in the Time Tracking section → enter time spent (e.g. 2h, 30m, 1d 4h) → set the date → click Save. Time tracking must be enabled in your project settings for Log Work to appear. Each entry is stored as a worklog attached to the issue.
Time logging in Jira is straightforward once you know where to look — but teams consistently run into the same problems: inconsistent formats, missing Log Work buttons, worklogs on the wrong issue, and no clear picture of what the team actually spent time on. This guide covers everything from the basic steps to admin setup and team best practices.
Already logging time and need to report on it? See: Jira Time Tracking Reports: What’s Built In, What’s Missing, and How to Get a Report by User
The time entry is immediately added to the issue’s worklog and the Time Spent field updates. If you set a remaining estimate, Jira updates that too.
Jira uses specific abbreviations for time units. Getting these wrong is the most common cause of failed or incorrect worklog entries.
| Format | Meaning | Example |
|---|---|---|
| w | Weeks | 1w = 1 week (5 working days) |
| d | Days | 2d = 2 working days (16 hours by default) |
| h | Hours | 3h = 3 hours |
| m | Minutes | 45m = 45 minutes |
| combinations | Mixed units | 1h 30m, 2d 4h, 1w 3d |
If Log Work is not appearing on your issues, time tracking may be disabled or misconfigured. Here’s how to check and fix it — you need Jira administrator access for these steps.
Even with global time tracking enabled, individual projects can have the Time Tracking field removed from their field configuration. If Log Work doesn’t appear on a specific project’s issues:
Users need the Work On Issues permission to log time. Go to Project Settings → Permissions and verify this permission is granted to the relevant roles. Without it, the Log Work button is hidden even if time tracking is enabled.
Logged the wrong amount of time, or logged it on the wrong issue? Here’s how to fix it.
Same path as editing — Work Log tab → three-dot menu → Delete. Deleting is permanent and cannot be undone.
One of the most common team disagreements about Jira time tracking is where to log time — on the sub-task, on the parent story, or on the epic. There’s no universally correct answer, but inconsistency within a team creates reporting problems.
| Approach | How it works | Best for |
|---|---|---|
| Log on sub-tasks only | Time rolls up to the parent issue automatically in Jira’s Time Tracking section | Teams that break work into sub-tasks and want granular tracking |
| Log on stories/tasks directly | Simpler — one level of tracking per piece of work | Teams without sub-tasks, or Kanban teams |
| Log on epics | Very high-level tracking only | Not recommended — too coarse for meaningful reports |
Pick one approach and document it in your team’s working agreement. Inconsistent logging — some people on sub-tasks, others on stories — produces time reports that are impossible to interpret correctly.
Based on working with 750+ Jira teams, these are the conventions that consistently produce clean, usable time data:
Original Estimate should be set when an issue enters the sprint — not after work is complete. If you set it after, it becomes a rationalisation of the actual time rather than a genuine prediction, which makes estimation accuracy reports useless.
End-of-week logging is consistently less accurate. A quick 2-minute log at the end of each working day produces data that’s reliable enough for billing, capacity planning, and retrospectives. Weekly logging produces rounded, approximate data that’s only useful for rough estimates.
If your team does client work or needs to distinguish activity types (development, review, meetings, support), use the Work Description field consistently. Even a simple convention — “DEV:”, “REVIEW:”, “MEETING:” — makes filtering worklogs by activity type possible.
Log time on the specific issue you worked on — not on a catch-all “miscellaneous” ticket. If the work doesn’t have a Jira issue, the work shouldn’t be happening or the backlog needs updating.
Verify your Jira time tracking settings match your actual working day. If your team works 7.5-hour days but Jira is configured for 8-hour days, every “1d” log will show slightly more time than was actually worked. A small mismatch across a large team produces significant errors in monthly reports.
Once your team is logging time, the natural next question is: how do you see what’s been logged? Jira’s native options are limited.
To find all issues where a specific person logged time in the last 30 days:
To see all time logged by your team this sprint:
This returns a list of issues — not a summary. To get total hours, export to CSV and sum the Time Spent column.
Jira has no native timesheet view. For a grouped per-user summary — total hours by person, by project, by sprint — without exporting to spreadsheets, Report Hub provides a Timesheet report directly inside Jira Cloud under Apps → Report Hub → Timesheets.
For the full guide on every time reporting option in Jira — including what’s native, what requires JQL workarounds, and how to get a time report by user — see: Jira Time Tracking Reports: What’s Built In, What’s Missing, and How to Get a Report by User.
Open the Jira issue → find the Time Tracking section → click Log Work → enter the time spent (e.g. 2h, 30m, 1d) → set the date → click Save. Time tracking must be enabled in your project settings for the Log Work option to appear.
Jira uses w (weeks), d (days), h (hours), and m (minutes). Examples: 2h for 2 hours, 30m for 30 minutes, 1d 4h for 1 day and 4 hours, 1w 2d for 1 week and 2 days. By default 1 day = 8 hours and 1 week = 5 days — your admin can change these values.
Go to Settings (gear icon) → Issues → Time Tracking → set the provider to JIRA provided time tracking → Activate. You can also configure working hours per day and week here. If Log Work still doesn’t appear on a specific project, check Project Settings → Issue Types → verify the Time Tracking field is included in the field configuration.
Yes. Open the issue → scroll to Activity → click the Work Log tab → find the entry → click the three-dot menu → Edit or Delete. Users can edit their own worklogs by default. Jira administrators can edit or delete any worklog.
Log Work doesn’t appear if time tracking is disabled globally, if the Time Tracking field has been removed from the issue type’s field configuration, or if your user role doesn’t have the Work On Issues permission. Ask your Jira administrator to check Settings → Issues → Time Tracking and your project’s field configuration.
Original Estimate is the time predicted before work begins. Time Spent is the total time actually logged via Log Work. Remaining Estimate is how much time is left on the issue. The gap between Original Estimate and Time Spent is what Jira’s Time Tracking Report measures — useful for understanding estimation accuracy over time.
Jira has no native team timesheet view. Use the Issue Navigator with JQL: worklogAuthor in membersOf('your-team') AND worklogDate >= -30d to find issues with recent team worklogs. For a grouped per-user summary without spreadsheet exports, use Report Hub’s Timesheet report under Apps → Report Hub → Timesheets.
Logging time in Jira is simple once the setup is correct — the Log Work button, the right time format, and a team convention about where and what to log. The problems almost always come from one of three places: time tracking not enabled, wrong field configuration, or no agreed team convention.
Get the logging right first. Once your team is consistently logging time, the reports become useful. For everything you can do with that logged data — from per-user summaries to cross-project timesheets — see: Jira Time Tracking Reports: What’s Built In, What’s Missing, and How to Get a Report by User.
Ready to Elevate Your Jira Setup?
Partner with Grandia Solutions to unlock expert configuration, reporting, and support services — tailored to your workflows. Whether you need custom dashboards, workflow automation, or long-term consulting, our team is here to make Jira work for you.