“Two-way sync” can mean anything from importing an issue list to reconciling edits to the same worklog. The label is not enough; the useful test is whether an edit made in Jira comes back into the tracker without being overwritten later.
Marketing pages use “sync” for several different operations: importing issue names, creating Jira worklogs, or reconciling edits to an existing entry. What people usually need to know is narrower: if a worklog gets edited inside Jira’s own UI, does that change come back into the tracker, and what happens if both copies changed before the next sync?
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.
Marketplace apps can solve the problem differently. Tempo operates inside Jira’s installed-app model. Clockify’s current Marketplace app explicitly documents two-way changes between Jira worklogs and Clockify entries, which is materially different from its older extension-led workflow. We dig into the remaining 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 is designed around installed apps. Planim Time deliberately avoids a Marketplace tenant install and authenticates as the user through OAuth or an API-token fallback. We poll instead of requiring an installed webhook app. The separate no-admin guide explains where site authorization and token policy can still create an admin gate.
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, just 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, whether you stop a timer or 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.
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, whether for accounting, for sprint review, or 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.)