Almost every Jira time tracker on the market advertises “two-way sync.” Almost none of them actually do it.
The marketing copy is technically defensible — most of these tools do read from Jira at some point, usually to import an issue list — and “two-way” sounds like a feature checkbox you’d be silly to ship without. But what people mean when they ask whether a tracker has two-way sync is something narrower and more demanding: if a worklog gets edited inside Jira’s own UI, does that change come back into the tracker, or does the tracker silently overwrite it on the next push?
That’s the failure mode we set out to actually fix when we built Planim Time, and it took us about four months longer than we’d planned.
What “sync” usually means in practice
Here’s the path most trackers ship. You start a timer. You stop a timer. The tracker creates a worklog entry locally and, when you click Push (or on a schedule), POSTs it to Jira’s worklog endpoint. Done. From the tracker’s perspective, the worklog is now Jira’s problem.
The hidden assumption in that design is that nothing else ever touches the worklog after it lands in Jira. In a single-engineer setup that’s mostly fine. The moment you’re on a team with a tech lead or a PM who corrects worklogs in Jira directly — bumping a 3h to a 4h because they know you also covered the standup, fixing a typo in the comment, reassigning to a sub-task — the assumption breaks.
The next time you edit anything about that entry in the tracker and push, the tracker does an UPDATE on Jira’s record using its own copy as the source of truth. Your lead’s edit gets silently overwritten. They re-edit. You push again. Round two. Whoever ran the loop last wins, and one of you spends a Tuesday morning trying to reconcile a sprint’s worth of worklogs by hand.
Tempo and Clockify both work around this differently — Tempo by treating its own UI as the canonical surface for worklogs, Clockify by leaning push-heavy and not promising round-trip. Both designs have their place; we dig into the trade-offs on Planim Time vs Tempo and Planim Time vs Clockify.
Why true two-way is hard to ship
The reason most trackers don’t do this isn’t laziness — it’s that Jira’s REST API is genuinely awkward for the use case.
Jira can emit webhooks for worklog events, but Cloud’s webhook system was designed around Connect and Forge apps with their own auth surface. For a desktop binary that talks to the user’s own Jira through their personal API token, the webhook path is fragile enough that we don’t rely on it. We poll instead.
Polling worklogs is fine in principle and awkward in detail. There’s no clean “give me everything that changed since timestamp T” endpoint at the worklog level — only worklog/updated, which returns IDs of worklogs touched since a cursor and leaves you to batch-fetch the actual fields. On a busy team that adds noticeable extra traffic per sync pass, and Jira Cloud’s rate limits are not generous.
The other awkward bit is conflict resolution. If a worklog was edited locally and remotely between two pulls, both copies have a real updated timestamp and a real author and real content, and you need a deterministic rule for which one wins. We considered last-write-wins (simple, surprises the user when their five seconds of typing get overwritten) and merge-by-field (clever, almost impossible to make legible). We landed somewhere in between.
How we actually do it
The pattern that ended up working has three layers.
On app launch we do a full pull: every worklog on every issue your JQL filter touches, over a recent window of activity. This is the “wake up and catch up” pass. It only fires once per session because it’s expensive on large workspaces.
While the app is open, a delta poll runs on a short timer. We hit worklog/updated with the cursor from the last successful pass, fetch what’s new, and merge it. The merge rule compares updated timestamps field by field: remote newer wins, local newer wins, and if both moved between polls, Jira wins, because Jira is the system of record your finance and reporting team trusts. When that overwrite happens we surface a small notification, so you know your edit was clobbered and can redo it deliberately.
Push happens on user action — stop a timer, save a worklog edit — without waiting for the next poll. The local version is marked dirty until Jira’s response comes back with a fresh updated timestamp, which we use as the new high-water mark.
The end result is the property we wanted: if your tech lead bumps a 3h to a 4h in Jira, you’ll see it in the tracker within roughly a minute, without lifting a finger, and your next edit won’t blow away their fix.
Where this still goes wrong
We’re not going to pretend it’s seamless.
The poll window means you can briefly see stale data. If you alt-tab to Jira, edit a worklog there, and immediately alt-tab back, the tracker will show the old version for a moment. Hitting refresh in the calendar forces a poll and closes the gap, but most users don’t, so they sometimes notice the lag.
On older Jira Server installations the worklog/updated endpoint doesn’t return enough information to drive a delta-poll cleanly. We fall back to a slower full-window pull there. It works but is heavier on the server, and larger Server deployments occasionally ask us to dial it back — there’s a config knob for that.
Deletes are the awkward ones. If a worklog gets deleted in Jira, our delta poll sees it disappear from the issue’s worklog list — but only if the issue itself is in our active filter. If the issue isn’t, we keep a stale local copy until you next look at that issue specifically. Closing this gap properly would require a full per-issue scan on every poll, which we’re not willing to pay for. So instead, when you click into an issue, we always do a fresh fetch of just that issue’s worklogs before rendering. It’s a soft fix but it covers the path users actually walk.
What it means for you
If you work alone, or on a team where worklogs are write-only — you set them, nobody else touches them — push-only is genuinely fine. You don’t need two-way sync, and a tracker that only pushes will work for you indefinitely.
If you work on a team where leads, PMs, or finance edit worklogs in Jira directly — for accounting, for sprint review, for any reason — push-only trackers cost you real time. Every week you’ll spend ten or twenty minutes reconciling discrepancies you didn’t know existed. The math on that compounds quickly: an engineer-hour a fortnight is more than what most of these tools cost.
That’s the case Planim Time for Jira is built for. If you’re in it, download Planim Time and point it at a real instance with real worklogs being edited by real teammates for a sprint. The two-way machinery either earns its keep in the first week or it doesn’t, and you’ll know which.
(We wrote separately about why the desktop tracker exists at all — that’s the why; this post is the how.)