2026-04-30 · 10 min read jira time-tracking tutorial

How to track time in Jira: every method, ranked by friction

Five ways to log time in Jira — native worklogs, Marketplace plugins, browser extensions, desktop apps, and the worklog API — ranked by setup effort.

By Vladimir Letiagin

“How do I track time in Jira” hides at least five different questions. Some of them are answered by a button that’s already in your Jira UI; others require an admin install, a browser extension, a separate desktop app, or a few lines of code against the REST API. The right answer for Jira time tracking depends on whether you log hours once a week or once an hour, whether your data needs to leave your machine, and whether the rest of your team is going to live in the same tool with you.

I’m the co-founder of Planim Time, one of the desktop trackers in this list. The bias is up front. The point of this post isn’t to argue desktop is the only answer — it’s to walk through every realistic method, the friction each one introduces, and let you pick by what your day actually looks like. Methods are ranked from “you can do it right now without installing anything” down to “this is a project.”

Method 1: Jira’s native worklog UI

You don’t need a third-party time tracker for Jira to log hours against an issue. Every Jira issue, on every plan from Free up, has a worklog field built in — that’s the native way to log time in Jira, and for some workflows it’s all you need. To use it:

  1. Open any Jira issue.
  2. Click the … (three-dot) menu in the top-right corner of the issue panel.
  3. Pick Add work log (sometimes labelled “Log work” depending on your Jira version).
  4. Enter a duration in Jira’s time format — 1h 30m, 2d, 45m, etc. — pick a date, optionally write a description, click Save.

That’s the entire mechanism. Worklogs created this way show up everywhere reports expect them: in the Time Tracking gadget on dashboards, in JQL queries (worklogAuthor = currentUser() AND worklogDate >= -7d), in REST API responses, and in any third-party tool that pulls Jira worklogs.

Friction: Low if you log once a day at end-of-day, painful if you want to track in real time. You’re typing durations after the fact, which means reconstructing what you did from memory, your git log, or your calendar — and the longer you wait the more wrong the numbers get. Anyone who’s tried to fill in a week’s worklogs on Friday afternoon knows exactly what that looks like.

When this is the right answer: You log time monthly or weekly for finance reporting, you don’t need timer accuracy, and you’re not tracking enough hours per day for the typing friction to matter. Solo consultants who already know what they did each day land here, as do engineers who only need worklogs to satisfy a PMO and don’t care about the underlying data themselves.

Method 2: An Atlassian Marketplace plugin

If your company already runs Jira and someone with admin rights is willing to install an app, Marketplace plugins like Tempo Timesheets and Clockwork add a richer time-tracking surface inside Jira itself. You get a timer button on every issue, a weekly timesheet grid, approvals, capacity planning, sometimes invoicing.

The setup is a one-time admin step: install the app from the Marketplace, grant project permissions, decide whether to enforce time tracking globally. After that every Jira user automatically has the tracker UI inside Jira, with no per-user installation. For teams above ~10 people that’s a real win — onboarding a new engineer means nothing more than adding them to Jira.

Friction: Low for end users (no install), medium for admins (one Marketplace setup), high for procurement if your company doesn’t already approve Marketplace vendors. Tempo, Clockwork and the rest are per-Jira-user pricing, which means every Jira user — including the ones who’ll never log a single hour — counts toward your seat bill once you outgrow free tiers. Worth doing the math before committing.

When this is the right answer: Your finance, PMO or HR team needs the data and someone above the engineering line is paying. We’ve covered the head-to-heads — Planim vs Tempo, Planim vs Clockwork — and they go into the trade-offs in detail. The short version: Marketplace plugins are the right shape when staying inside Jira itself is the requirement, not just a preference.

Method 3: A browser extension that pushes worklogs to Jira

If you don’t want a Jira admin involved at all, a class of trackers — Clockify is the most common — work as browser extensions that surface a timer button on Jira issue pages. You click start when you open the issue, click stop when you’re done, and the extension pushes the resulting time entry to Jira’s worklog API on your behalf.

The appeal is zero admin involvement: install the Chrome or Firefox extension, sign in with your own credentials, and you’re tracking the next time you open a Jira issue. The sign-in usually happens through the extension’s own SaaS account, where time entries also get stored as a parallel record.

Friction: Lowest possible setup for an individual engineer, but the worklog model is one-way. You push to Jira; you don’t pull. If a teammate edits a worklog inside Jira directly, your tracker doesn’t see it, and the next push from your side will silently overwrite their fix. There’s a longer post on this specific failure pattern; the short version is that one-way push is the single biggest reason teams eventually outgrow extension-based trackers.

When this is the right answer: You’re a single engineer in a company that doesn’t manage time centrally, you want zero admin touch, and the parallel-store problem is acceptable because you’re the only one editing your worklogs. The moment a tech lead or a PM starts editing your hours in Jira to fix something, this method starts breaking.

Method 4: A native desktop time tracker for Jira

A desktop time tracker for Jira lives in your menu bar (macOS) or system tray (Windows / Linux), starts a timer with one click, and pushes worklogs to Jira through your own API token. The two main reasons to use one over a Marketplace plugin or a browser extension: it survives Jira outages, and it doesn’t require any cloud account between you and Jira.

Planim Time is the one I work on. Setup is roughly:

  1. Download the installer for your OS (DMG / EXE / AppImage / .deb).
  2. Generate a Jira API token at id.atlassian.com and paste it into the app on first launch.
  3. Pick a JQL filter (anything that returns the issues you care about) — “my open issues in the current sprint”, “issues assigned to me, not done”, whatever.
  4. Click an issue, hit start.

The token goes into your OS keychain rather than our servers — same vault your browser uses for saved passwords. Worklog sync runs both ways, so if a teammate edits an entry in Jira directly, the tracker pulls that change in on its next poll instead of overwriting it. Tracking continues offline; reconciliation happens on reconnect. (For the deeper rationale on storage and sync, see the security review and two-way sync write-up.)

Friction: Medium one-time setup (install, paste token, pick filter), zero day-to-day. The trade-off is that the install is per-machine, so if you switch between a laptop and a desktop you paste twice. There’s no admin-side “see everyone’s hours” panel out of the box; for that you upgrade to the Team plan, which rolls up workspace stats.

When this is the right answer: You spend most of your day in Jira, you want a timer that’s running before Jira finishes loading, and your IT or security team prefers credentials staying on user devices instead of in another vendor’s database. We have a longer write-up on why we shipped a desktop binary instead of a Marketplace plugin, and a security review of how each tracker in this category handles the token, if that side of it matters.

(The free tier is the whole tracker, not a teaser. If you want to evaluate, download Planim Time and point it at a real Jira instance for a sprint.)

Method 5: Talk directly to Jira’s worklog REST API

For a fully scripted workflow — say, you want to log hours from a CI job, a git commit hook, or a custom CLI — the worklog endpoint is the bottom layer everything else is built on:

POST /rest/api/3/issue/{issueIdOrKey}/worklog
Authorization: Basic <base64(email:api-token)>
Content-Type: application/json

{
  "timeSpentSeconds": 3600,
  "started": "2026-04-30T09:00:00.000+0000",
  "comment": {
    "type": "doc",
    "version": 1,
    "content": [
      { "type": "paragraph", "content": [{ "type": "text", "text": "Reviewed PR #4287" }]}
    ]
  }
}

A couple of things that aren’t obvious from the example:

  • The comment field on Jira Cloud uses Atlassian Document Format (ADF) — the verbose JSON shape above. On Jira Server / Data Center, the same field accepts plain text or wiki markup instead. If you cross-target both, branch on cloudId or build a small ADF helper.
  • timeSpentSeconds is the source of truth; you can also send timeSpent (“1h”, “1h 30m”) but the API rounds it to seconds anyway, so just send seconds.
  • Time tracking has to be enabled in your Jira project’s configuration; if it’s off (or estimation is set to a non-time unit), the worklog POST returns a 400 with a generic-sounding error.
  • Atlassian’s worklog REST docs cover the full schema and the GET / PUT / DELETE shapes for read-back, edit, and remove.

Friction: High one-time (you’re writing code), zero recurring (the script runs every time without you). You’ll also reinvent edge cases — token rotation, Atlassian’s API rate limits, retries, the ADF comment format — that a tracker handles for you. But for some workflows it’s the only fit: nightly billing exports, automated time tracking against PR review hours, integration into an internal time-keeping system.

When this is the right answer: You have a use case that doesn’t fit any UI — a script that logs time without a human present, a pipeline that calculates hours from external data and writes them to Jira, an internal portal that already manages timesheets and just needs a Jira sync layer. None of the trackers above can do those jobs, because by definition there’s no user clicking start.

Decision tree

If you came here for one answer, here’s the compressed version:

  • You log hours weekly for finance: Jira’s native worklog UI is enough. Don’t add a tool you don’t need.
  • Your company already pays for Marketplace tools: A plugin like Tempo or Clockwork pays for itself the moment a director needs an approval workflow.
  • You want zero admin involvement and you’re tracking solo: A browser extension (Clockify) gets you tracking in five minutes. Plan to outgrow it once teammates start editing your worklogs in Jira.
  • You spend your day in Jira and want a timer that survives outages: A desktop tracker. Either Planim Time or one of its competitors — the round-up lays out the alternatives by use case.
  • You’re scripting: Skip the UI layer entirely and call /rest/api/3/issue/{key}/worklog directly.

The shape of the right answer is “match the friction of the tool to the cadence of your tracking.” A weekly entry doesn’t need a desktop app. A second-by-second timer doesn’t survive in a worklog form. Pick by how often you’re actually pressing start, and the rest narrows itself.