How to log time in Jira: a practical guide to worklogs

Before you start: enable time tracking

If you can't find anywhere to log work on an issue, the problem is almost always configuration, not you. Three things have to be true:

1. Time tracking is turned on for the instance. In Jira Cloud, a site admin goes to Settings (gear icon) → Issues → Time tracking. In Jira Server or Data Center, it's Administration → Issues → Time tracking. This is also where the working-time conversion lives: by default, one day is 8 hours and one week is 5 days. If your company runs on 7.5-hour days, change it here, otherwise "1d" will mean something different from what people assume.
2. You have permission to log work. In the project's permission scheme this is usually called Work on issues. Separate permissions control editing and deleting your own or other people's worklogs.
3. The Time tracking field is on the project's screens. In company-managed projects, the field has to be on the relevant screen for the issue type. In team-managed projects, the time tracking feature or field needs to be added in the project settings. Exact menu names vary by Jira version and project type.

How to log time in Jira Cloud

The Cloud issue view has changed several times over the years, so the exact placement depends on your layout. The common paths are:

• Time tracking field. In the issue's details panel, click the time tracking bar (it may show "No time logged"). A Time tracking dialog opens.
• The … (more actions) menu. At the top of the issue, open the menu and look for Log work or Log time.
• Command palette. In many Cloud layouts, pressing . on an open issue brings up a search box for issue actions; type "log" and pick the log work action. If it doesn't work on your site, the menu path always does.

The dialog asks for Time spent, Time remaining, a date and time started, and a work description. Time spent uses Jira's duration notation: w, d, h, m. So 1w 2d 3h 30m is valid, and with default settings it equals 5 + 2 days, i.e. 59.5 working hours. For daily logging you will mostly type things like 45m or 2h 15m.

Pay attention to the start date. It defaults to now, so if you're filling in yesterday on a Monday morning, change it, or your weekly timesheet will show everything on the wrong day.

How to log work in Jira Server and Data Center

On Data Center, open the issue and choose More → Log work. The dialog has a few more knobs than Cloud's:

• Time spent: same notation, e.g. 3h 30m.
• Date started: the day and time the work began.
• Remaining estimate, with four options:
  • Adjust automatically: subtract the time spent from the remaining estimate.
  • Leave estimate unset or use the existing estimate: don't touch it.
  • Set to: replace the remaining estimate with a new value.
  • Reduce by: subtract a specific amount, different from what you logged.
• Work description: the comment that appears in the worklog.

"Adjust automatically" is the right default for most people. Use "Set to" when you know the estimate was wrong, for example after realizing a two-hour fix is really a two-day rewrite.

Quick reference: Cloud vs Data Center

Logging time from commits (smart commits)

If your repository is connected to Jira (Bitbucket, GitHub or GitLab through the relevant integration), you can log work straight from a commit message:

git commit -m "CASE-1423 #time 2h 30m Fixed token refresh on expired sessions"

Jira parses the issue key, the #time command and the duration, and uses the rest as the worklog comment. Two caveats: the email on your commit has to match a Jira user who is allowed to log work, and the worklog is created when Jira processes the commit, not when you wrote the code. Squashing or rebasing can also replay the message, so watch for double entries.

Smart commits are great for developers who already reference keys in every commit. They are bad for meetings, code review and support, which never produce commits.

Logging work with the REST API

For scripts and integrations, Jira Cloud exposes POST /rest/api/3/issue/{issueIdOrKey}/worklog. Version 3 expects the comment in Atlassian Document Format (ADF), and started must include milliseconds and a UTC offset:

curl -X POST \
  -u "you@company.com:$JIRA_API_TOKEN" \
  -H "Content-Type: application/json" \
  "https://your-site.atlassian.net/rest/api/3/issue/OPS-77/worklog" \
  -d '{
    "timeSpentSeconds": 5400,
    "started": "2026-10-16T09:00:00.000+0000",
    "comment": {
      "type": "doc", "version": 1,
      "content": [{"type": "paragraph",
        "content": [{"type": "text", "text": "Rotated staging certificates"}]}]
    }
  }'

On Data Center, the equivalent is /rest/api/2/issue/{key}/worklog, where comment is a plain string. Authentication is typically a personal access token sent as a bearer header on recent versions. In both cases, the endpoint accepts an adjustEstimate query parameter if you want to control the remaining estimate the same way the dialog does.

Where worklogs show up

Each worklog appears under the issue's Activity → Work log tab with the author, the start date, the duration and the comment. The time tracking bar in the issue details compares three numbers: the original estimate, the time logged, and the remaining estimate. When logged plus remaining exceeds the original estimate, the bar shows the overrun, which is often the first signal that a task was underestimated.

Worklogs are also what reports, filters and timesheet apps read. If they're wrong in the issue, they're wrong everywhere downstream.

Common mistakes

• Logging on the epic instead of the story or subtask. Time on an epic is hard to attribute, and depending on your setup it may not roll up the way you expect. Log on the issue where the work actually happened.
• Wrong date or timezone. A worklog started at 23:30 in one timezone can land on the next day in a teammate's report. Log against your own working day and double-check the start time when catching up.
• Duplicates. Re-running scripts, replayed smart commits, or logging the same meeting from two devices. Scan the Work log tab before bulk entry.
• Rounding drift. Rounding every entry up to 30 minutes turns a real 6.5-hour day into 8. Pick a granularity (we use 15 minutes) and round to the nearest, not always up.

How to write good worklog descriptions

A worklog comment should let someone, including you three weeks later, understand what the time bought. What works for us:

• One worklog per task per day. Merge the morning and afternoon sessions on CASE-1423 into one entry rather than five fragments.
• Start with a verb. "Fixed", "Reviewed", "Investigated", "Deployed".
• Name the concrete thing. A component, a PR, a customer, an environment.

Examples:

• CASE-1423 · 2h 30m · Fixed token refresh for expired SSO sessions, added regression test
• OPS-77 · 1h 30m · Rotated staging TLS certificates, updated runbook
• CASE-1501 · 45m · Reviewed PR #312 (invoice export), requested changes

"Work on task" or "dev" tells nobody anything, and those are the entries that get questioned at month end. For a full routine, see how to fill your timesheet in 10 minutes.

A note on Tempo

If your company uses Tempo Timesheets, you'll log time in Tempo's own interface. Tempo stores its worklogs and keeps them in sync with Jira worklogs, so entries still show up on the issue's Work log tab. The rules above (right issue, right date, clear description) apply the same way. If you're weighing whether you need Tempo at all, we compared the options in Tempo Timesheets alternatives.

How to automate it

Everything above assumes you remember what you did. That's the weak link. By Friday, most people reconstruct their week from calendar invites, Slack history and guesswork, and the result underreports the small stuff: the 20-minute review, the quick prod check.

The better approach is to reconstruct the day from activity you already generate:

• Window titles. Jira tabs carry the issue key, e.g. "[CASE-1423] Token refresh fails after SSO timeout".
• Git branches. A branch named feature/CASE-1423-token-refresh in your IDE's title bar identifies the task without any guessing.
• Apps and domains. Time in a meeting app or on a monitoring dashboard can be matched to an ops or meetings issue.

Then let a tool draft the worklogs, and you approve them. That's the idea behind Timesheet Tracker, an automatic Jira timesheet for Windows. It runs in the tray and records the active app, window title, browser tab domain and idle or lock time locally on your PC. It finds Jira keys in window titles, URLs and git branches on the device, with no AI involved. For what's left over, the Sort my day button lets AI assign the remaining blocks and draft one worklog per task. Only masked titles, app names, domains and durations are sent for that step, never full URLs, page content, screenshots, keystrokes or your Jira token. There's also a "No AI" mode. Details are on the privacy page.

You review the drafts, edit anything that looks off, and confirm. Timesheet Tracker writes them to Jira Cloud or Server/Data Center without creating duplicates, or exports CSV. It has no screenshots and no manager reports; it's built for individuals who log their own time. It's coming soon to the Microsoft Store and free during early access. If you want the broader picture, see automatic time tracking software for Windows.