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, ours included.
Planim Time automates two of those layers, captures nothing about your day beyond the length of an input gap, 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, 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 capture your day. No keyboard or mouse monitoring, no app or window logging, no activity scores. The one input-adjacent signal we read, as of v0.4, is idle detection: a single number the OS already maintains (seconds since your last input), checked locally, never stored, never sent anywhere. And notice which layer it lands on. An idle gap gets a prompt when you return (keep it, subtract it, or stop the timer at the moment you left), not a silent edit, because an input gap is a weak signal: it can’t tell a coffee run from a whiteboard session. Everything our automations react to still lives in Jira, signals from the work rather than from the worker. A status change is something you did to the project; that kind of signal is trustworthy enough to act on. An input gap is something a sensor noticed about your body, so it only ever earns a question. Acting silently on weak signals is how time trackers drift into being monitoring products, and it’s the line we won’t cross. The privacy position is covered in the screenshots post; the tracker still 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.