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

“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.

Planim Time, one of the desktop trackers in this list, is ours. 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.”

If admin access is the blocker, read Jira time tracking without admin rights first. It separates Marketplace installation, project permissions, OAuth site authorization, and API-token policy instead of treating them as one gate.

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. This same native worklog is available in the Jira mobile app, with the same after-the-fact typing and no timer; Jira time tracking on mobile covers when the phone is the right surface for it.

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 starts from Jira

If you don’t want a Marketplace app installed in Jira, browser-extension trackers can 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 records the entry in the tracker’s own account. Whether it also creates a native Jira worklog depends on the product and plan, so verify that exact path before rollout.

The appeal is per-user setup: 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 Jira integration can still hit an OAuth approval or Marketplace gate, depending on the product. The sign-in usually also creates an account in the extension vendor’s SaaS, where time entries become a parallel record.

Friction: Lowest possible setup for an individual engineer, but an extension can disappear with the tab and may make the vendor’s cloud, rather than Jira, the primary record. Some integrations are import-only, some write Jira worklogs, and some now reconcile both ways. The two-way sync write-up explains the checks that distinguish them.

When this is the right answer: You’re a single engineer, most work happens in the browser, and a general-purpose timesheet is more important than an offline Jira-first workflow. If Jira must remain authoritative, test an edit in Jira and confirm exactly where it appears before choosing the extension.

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 syncs worklogs through your Jira identity. The two main reasons to use one over a Marketplace plugin or a browser extension: it survives Jira outages, and a single engineer can evaluate it without a Jira admin install.

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

1. Download the installer for your OS (DMG / EXE / AppImage / .deb).
2. Click Sign in with Atlassian, approve access in the browser, and choose the Jira site. If your organisation requires it, Use API token instead remains available as a fallback.
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.

Long-lived OAuth credentials go into your OS keychain, the same vault your browser uses for saved passwords. A short-lived broker passes the OAuth exchange and refresh responses back to the app without retaining them as the long-term store. If you choose the API-token fallback, that token stays on the device and the app talks directly to Jira. Worklog sync runs both ways, and tracking continues offline until reconciliation on reconnect. (For the deeper rationale, see the credential security review and two-way sync write-up.)

Friction: Medium one-time setup (install, sign in, pick filter), zero day-to-day. The trade-off is that the install is per-machine, so each computer needs its own sign-in. Team-wide features live on the Team plan rather than an admin-side Marketplace panel.

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 uses Atlassian Document Format (ADF), the verbose JSON shape above. Build a small helper for the document wrapper instead of scattering it through the integration.
• 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.
• In Jira Cloud, time tracking is always enabled and there is no project-level switch: a 400 from this endpoint is nearly always a malformed payload (the ADF comment or the started format), while a missing Work on issues permission comes back as a 403.
• The full schema, the GET / PUT / DELETE shapes for read-back, edit, and remove, and the bulk worklog/updated endpoints are in our Jira Worklog REST API guide, which links out to Atlassian’s reference for each call.

Friction: High one-time (you’re writing code), zero recurring (the script runs every time without you). You’ll also reinvent edge cases that a tracker handles for you: token rotation, Atlassian’s API rate limits, retries, the ADF comment format. 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 work mainly in the browser and want to avoid a Marketplace install: A browser extension is the lowest local-install option; verify its authorization path and whether its hours actually become native Jira worklogs.
• 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.