Track Time in Jira from the Terminal

atlassian-cli is an independent, community open-source project, not affiliated with, endorsed by, or sponsored by Atlassian, and is not Atlassian's official CLI (acli). Product names are used only to identify compatibility.

Looking for a jira worklog CLI workflow? You can manage Jira time tracking from the terminal today: set original and remaining estimates on an issue, find every issue that has time logged against it with JQL, and roll those results into a weekly report with jq. This guide shows the exact atlassian-cli commands, and it is honest about where the CLI stops and Jira's worklog REST endpoint takes over.

A quick note on what this tool is: atlassian-cli is an independent, community, MIT-licensed open-source project. It is not Atlassian's official CLI (acli) and is not affiliated with, endorsed by, or sponsored by Atlassian. Use the official acli if you need first-party vendor support; use atlassian-cli if you want a single free Rust binary spanning Jira, Confluence, Bitbucket, and JSM.

How Jira Tracks Time

Jira splits "time" into two related but distinct concepts, and knowing the difference is what makes the CLI commands below make sense:

• Estimates. The timetracking field holds an original estimate (how long you think the work will take) and a remaining estimate (how much is left). These are values you write to the issue.
• Worklogs. Each worklog is a discrete entry: a person logged N minutes on a specific date, optionally with a comment. Jira sums those entries into the issue's time spent. Worklogs are append-only records, not a single editable field.

That split matters because different commands touch different layers. Setting an estimate is a normal field update. Selecting issues by who logged time, and when, is a JQL query. Reading the exact minutes inside each worklog entry is a separate REST call. The rest of this post walks each layer in turn.

What a Jira Worklog CLI Can Do Today

Before the commands, here is a candid map of the terrain. atlassian-cli is issue-first: it is excellent at writing estimates and at selecting issues by worklog criteria, and it hands off exact per-entry minutes to Jira's REST API. No invented flags here, only what the command reference documents.

In short: the CLI covers estimate upkeep and worklog-driven reporting end to end, and you drop to the REST API for the two rows marked "Not yet." The final section shows how to bridge that gap.

Set and Adjust Estimates

The timetracking field is a standard Jira field, so you write it through the generic --field escape hatch on jira issue update. The flag takes key=JSON, and Jira parses estimate strings like 3d, 4h, or 30m:

# Set the original and remaining estimate on an issue
atlassian-cli jira issue update DEV-42 \
  --field 'timetracking={"originalEstimate":"3d","remainingEstimate":"1d"}'

As work progresses, keep the burndown honest by writing just the remaining estimate. Run this at the end of the day, or wire it into a commit hook:

# Knock the remaining estimate down as you make progress
atlassian-cli jira issue update DEV-42 \
  --field 'timetracking={"remainingEstimate":"4h"}'

The same --field mechanism sets any field on the edit screen, so you can pair an estimate change with, for example, a custom field in a single call. Just make sure timetracking is on the issue's edit screen in your Jira configuration, otherwise the API rejects the write.

A note on units: Jira reads estimate strings as w (weeks), d (days), h (hours), and m (minutes), and a "day" defaults to whatever your site's time tracking settings define (commonly eight hours). So 1d and 8h can mean the same thing depending on configuration. If your reports look off by a constant factor, check the working-hours setting before blaming the CLI.

Find Issues by Worklog with JQL

Jira's JQL exposes three worklog-aware fields: worklogDate, worklogAuthor, and worklogComment. Because jira issue search passes JQL straight through, you can select issues by who logged time and when, without any special worklog subcommand.

Which issues did I touch this week?

# Every issue you logged time on since Monday
atlassian-cli jira issue search \
  --jql "worklogAuthor = currentUser() AND worklogDate >= startOfWeek()" \
  --limit 100

currentUser() and startOfWeek() are built-in JQL functions, so this query travels with you across profiles. Swap in a rolling window with worklogDate >= -7d, or target a teammate with worklogAuthor = "alex@example.com".

What did the whole team log against a project this sprint?

# All issues in DEV with worklog activity in the last 14 days
atlassian-cli jira issue search \
  --jql "project = DEV AND worklogDate >= -14d" \
  --limit 200

The default table output is fine for a glance. For anything you want to slice, add --format json and pipe it onward, which is the next section.

Build a Weekly Report with jq

The JSON that jira issue search emits is a flat array. Each row carries key, summary, status, assignee, and issue_type. That is enough to build a genuinely useful activity report: which issues had time logged, grouped by the person they are assigned to.

# Count issues worked on this week, grouped by assignee
atlassian-cli jira issue search \
  --jql "project = DEV AND worklogDate >= startOfWeek()" \
  --limit 200 --format json \
  | jq 'group_by(.assignee)
      | map({assignee: .[0].assignee, issues: length})
      | sort_by(-.issues)'

That returns a tidy leaderboard of activity for a standup or a sprint retro:

[
  { "assignee": "Priya Menon", "issues": 7 },
  { "assignee": "Alex Doe", "issues": 5 },
  { "assignee": "Sam Lee", "issues": 2 }
]

Group by .status to see whether logged work is landing in Done or piling up In Progress, or by .issue_type to split time across bugs versus features. One honest caveat: this counts issues, not hours. It answers "what got worked on and by whom," which is what most weekly reviews actually need. When you need the exact minutes, keep reading.

If you plan to parse the output programmatically, add the global --envelope flag. It wraps the array in {"data": [...], "count": N} so a downstream script can read the count without re-scanning the list; your jq path then starts at .data[] instead of .[]. For ad hoc reporting at the terminal, the bare array is simpler to pipe.

Export and Script a Weekly Timesheet

For a timesheet you can hand to someone in a spreadsheet, export the worklog-filtered issue set. Search writes CSV directly, and jira bulk export handles larger pulls with pagination:

# CSV of everything you touched this week, straight to a file
atlassian-cli jira issue search \
  --jql "worklogAuthor = currentUser() AND worklogDate >= startOfWeek()" \
  --format csv --output timesheet.csv

# Larger export: all worklog activity this month for a project
atlassian-cli jira bulk export \
  --jql "project = DEV AND worklogDate >= startOfMonth()" \
  --output worklog-month.json --format json

Chain these into a single script you run every Friday. This one prints your week's activity, writes a CSV, and shows the per-assignee breakdown:

#!/bin/bash
# weekly-timesheet.sh, your Jira worklog activity for the week
set -euo pipefail

PROFILE="work"
PROJECT="DEV"

# 1. Issues you personally logged time on since Monday
atlassian-cli jira issue search --profile "$PROFILE" \
  --jql "worklogAuthor = currentUser() AND worklogDate >= startOfWeek()" \
  --format csv --output timesheet.csv

echo "Wrote timesheet.csv"

# 2. Team activity for the project, grouped by assignee
atlassian-cli jira issue search --profile "$PROFILE" \
  --jql "project = $PROJECT AND worklogDate >= startOfWeek()" \
  --limit 200 --format json \
  | jq 'group_by(.assignee)
      | map({assignee: .[0].assignee, issues: length})
      | sort_by(-.issues)'

echo "Weekly summary complete."

The --profile flag targets a specific authenticated account, so the same script works across a personal and a work Jira site. For a scheduled, production-grade version of this pattern, see the Jira Sprint Report runbook.

Logging Individual Worklog Entries

Two things live outside the CLI's issue commands today: posting a discrete worklog entry (log 2h on Tuesday with a comment) and reading the exact minutes inside each entry. Both are handled by Jira's worklog REST endpoint:

• POST /rest/api/3/issue/{key}/worklog to add an entry with timeSpent, started, and an optional comment.
• GET /rest/api/3/issue/{key}/worklog to read every entry, each with its author, start time, and seconds logged.

The clean pattern is to let atlassian-cli do the selecting and the REST call do the logging: use jira issue search to find the right issue keys by JQL, then loop over them to post or fetch worklogs. That "select with the CLI, act with the API" bridge is covered in using the Jira API from the command line. If you are stitching worklog reporting into a broader ticket workflow, the Jira task management from the CLI guide covers the issue lifecycle those worklogs attach to.

FAQ

Related Resources