Fully automatic Jira time tracking does not exist. No product on the market watches you work and writes correct worklogs to Jira with nobody in the loop. What “automatic” covers, on every pricing page that uses the word, is one or more of three narrower features: automatic capture (the tool records which apps, documents, or meetings filled your day), automatic triggers (a timer starts or stops in response to a signal), and automatic delivery (finished entries are pushed to Jira’s worklog API so nobody retypes them). The step in the middle, where someone confirms that those ninety minutes belong on PROJ-214 as billable work, is manual in every mainstream tool. Including the one I build.
I co-founded Planim Time, a desktop Jira tracker that automates two of those layers and deliberately stops there. This post takes the word “automatic” apart: which jobs inside a worklog actually automate, what each product that markets the term really does, and the questions that separate a useful automation from a demo trick.
A worklog is four jobs, and only two automate well
Getting one honest worklog into Jira means doing four distinct things. Vendors blur them; pulling them apart explains almost every disappointment with “automatic” tracking.
| Job | What it is | Automates? |
|---|---|---|
| Capture | Noticing that time was spent, and on what | Yes, reliably |
| Attribution | Deciding which Jira issue the time belongs to | Partially, by heuristics |
| Judgment | Deciding it was work, and loggable | No |
| Delivery | Writing the worklog into Jira | Yes, completely |
Capture is a solved problem. An OS-level agent can record every foreground window, a calendar integration can list every meeting, an IDE plugin can see every file you touched. Machines are genuinely better at this than people: nobody’s memory of last Tuesday beats a timestamped activity log.
Delivery is solved too. The worklog REST API takes an issue key, a start time, and a number of seconds. Any tool that has those three values can file the worklog without you, and the good ones do.
Attribution is where automation gets partial. Heuristics exist: an issue key in a browser tab title, a branch named PROJ-214-fix-retry, a calendar event called “PROJ sprint planning”. They cover the well-labelled part of the day. They miss the code review you did across six tabs, the production incident that touched four issues, the hour of thinking that happened in a notebook. In my own activity log, the cleanly attributable fraction of an engineering day is well under half, and I build attribution heuristics for a living.
Judgment does not automate, because it isn’t a perception problem. Was the twenty minutes in Slack work on the issue or a tangent? Does the interview go on a worklog at all? Is the build wait loggable? These are policy questions, answered differently by every team, and sometimes differently by the same team before and after a billing deadline. A model can guess; only a person can commit.
The market phrase “automatic time tracking” almost always means: automated capture, heuristic attribution, human judgment, automated delivery. The human is still in the loop. The automation just moved them from authoring entries to approving them.
What each “automatic” product actually does
Concrete examples, checked against vendor documentation in June 2026.
Activity capture tools. Clockify’s Auto Tracker records every program and site you view for more than ten or fifteen seconds (the threshold varies by OS), keeps the log local to your machine for 45 days, and, notably, adds nothing to your timesheet by itself. You select recorded activities and convert them into time entries by hand. Timely runs the same capture model with an AI layer that drafts the entries for you, synced back to Jira as worklogs once you confirm. In both cases the automatic part produces an activity log. The worklog still goes through you.
Suggest-then-confirm inside Jira. Tempo’s automated time tracking pulls signals from your calendar, VS Code, JetBrains, and GitHub activity and turns them into cards in its My Work view; you log each one with a click. This is the same four-job split wearing a timesheet UI: capture and delivery are Tempo’s, attribution is a suggestion, judgment is your click.
Trigger automation. Toggl’s autotracker fires on window titles: match a keyword and it can notify you or start a timer outright. Planim Time’s triggers listen to Jira instead, which I’ll get to below. Triggers don’t capture a full day; they automate the two moments people actually forget, start and stop.
Scripts. The only literally automatic option. A cron job that turns yesterday’s calendar into worklogs, a commit hook that logs against the branch’s issue key, a CI step that records review time: all real, all human-free at runtime, all built on the same worklog API. The judgment didn’t disappear, it moved into the rules you wrote, and it ages exactly as well as those rules do.
Why nothing writes to Jira without asking
It would be easy to skip the confirmation click. Every vendor above has the issue key, the duration, and API access; auto-filing the suggestion is one if-statement. Nobody mainstream ships that if-statement, and the reason is worth making explicit.
An activity log is private. A worklog is not. It feeds the team’s reports, the client’s invoice, the PM’s burndown, payroll in some shops. A wrong activity record costs nothing; a wrong worklog is a correction, an awkward standup question, sometimes a billing dispute. The asymmetry between a one-second confirmation click and a wrong entry in a shared system of record is so lopsided that even Clockify, whose capture is the most aggressive in the list, refuses to move activities into the timesheet on its own.
When a tool does write silently (a misconfigured trigger, an over-eager script), you get phantom hours: a timer that started from a stray window focus and ran through lunch. Phantom worklogs are worse than missing ones. A missing worklog you can backfill from evidence. A phantom one sits in Jira looking exactly like the truth, and you find it during invoicing, if at all. That FAQ answer in our methods round-up (“there is no fully automatic mechanism”) was written from a support inbox, not from theory.
Where we drew the line in Planim Time
Planim Time automates triggers and delivery, skips capture entirely, and the boundary between its two trigger features is the clearest example I have of where “automatic” stops being safe.
Auto-stop is automatic. If a timer is running on an issue and that issue transitions into a status you’ve configured (Done, In Review, whatever your workflow calls finished), the timer stops and you get a notification after the fact. We ship this as a real automation because the signal is unambiguous and you authored it: you moved the card. The machine isn’t inferring that work ended, it’s reacting to you saying so in the system of record.
Auto-start is only a suggestion. When an assigned issue moves into a status like In Progress, the app shows a “Start tracking?” notification, one click to begin. We don’t start the timer silently, and that asymmetry with auto-stop is deliberate. A transition to Done reliably means the work stopped; a transition to In Progress does not reliably mean the work started this second. Maybe a PM dragged the card during planning. Maybe you start after the meeting. Stopping a real timer slightly early is a rounding error you’ll notice; starting a phantom one is fabricated data you won’t.
The third piece is a periodic “Still working?” nudge while a timer runs long, which is not automation at all, just a cheap defence against the timer-through-lunch failure that trigger systems are prone to.
What we don’t do is watch input. No keyboard or mouse monitoring, no idle detection, no app capture. Partly that’s the privacy position covered in the screenshots post, but it’s also an architectural choice about where signals come from: everything our triggers react to lives in Jira, signals from the work rather than from the worker. A status change is something you did to the project. An input gap is something a sensor noticed about your body. The first kind makes automation trustworthy; the second kind is how time trackers drift into being monitoring products. It also means the tracker works as a plain native desktop timer with nothing running that you’d hesitate to explain to your team.
Four questions for any page that says “automatic”
If you’re evaluating a tool on this promise, the marketing term decomposes under four questions:
- Does it ever write a worklog to Jira without an explicit confirm? If yes, ask how mistakes get found and fixed, because they will exist and Jira is where your team will read them.
- Where does the captured activity data live, and who can see it? Local-only with retention limits (Clockify’s model) and vendor-cloud-with-manager-dashboards are very different products sold under the same adjective.
- How does attribution work? Window titles, branch names, calendar parsing, AI guessing, or you. Then estimate what fraction of your day carries those labels. A consultant living in well-named meetings and an engineer deep in a debugger get very different mileage from the same heuristics.
- What happens to the unlabelled rest? Meetings without issue keys, review, thinking, interruptions. The honest answer for most engineering time is “you assign it manually”, and the tool’s real value is how fast it makes that step.
The honest version of “automatic” is this: capture saves you reconstructing the day, triggers save you the forgotten start and stop, delivery saves you the retyping. That’s most of the friction gone, and it’s worth paying for. The judgment about what your time was and where it belongs stays yours. A tool that claims otherwise hasn’t removed that decision; it has just hidden where it gets made, and you’ll meet it again in your invoices.