DEV Community: Vladimir Letiagin

How to track meeting time in Jira (and see how much of the sprint it eats)

Vladimir Letiagin — Sun, 01 Nov 2026 18:12:03 +0000

Every few months someone asks Atlassian Community how to track meeting time in Jira, and the thread fills with the same three answers. Jira has no notion of a meeting. Time exists only as worklogs, and a worklog must belong to an issue. So meeting time either gets an issue to live on, or it quietly disappears and the sprint looks like it had five more productive days than it did. Where to log it is the first half of this. The second half is reading the number and letting Planim Time fill it in from your calendar.

Three places meeting time can live

A ceremonies issue per sprint. Create OPS-15 Sprint 42 ceremonies with the sprint, and standups, planning, refinement and retro all get logged there. The point is the report: at the end of the sprint the issue's time spent is your ceremony cost, one number, comparable sprint to sprint. Some teams make it one issue per quarter instead; the per-sprint version is easier to compare.

The issue the meeting was about. A design review of the checkout flow is checkout work. A call with finance about refunds is refund work. Logged on those issues, the time shows up where it belongs in estimates versus actuals, and in anything billable. Standups don't belong here.

Not logging it, and cutting capacity instead. Some teams plan 6 hours a day instead of 8 and never log a meeting. That works for sprint planning until someone asks for a timesheet or wants to know why the sprint underdelivered.

Most teams end up with the first two together: ceremonies on the sprint issue, topic meetings on their issue. Write that rule down once, so nobody has to decide per meeting.

Reading the number

Once meetings have a home, the questions become answerable.

How much of the sprint went to ceremonies: open the ceremonies issue, time spent is the answer. For the trend, a JQL filter like summary ~ "ceremonies" ORDER BY created DESC lists them, and a worklog report or a CSV export gives you the series.

How much of a feature was meetings: on the feature issue, the worklog comments tell you. That only works if the comment names the meeting, like "Design review: checkout flow, 1h", and not just "meeting".

Per person: Jira's built-in reports stop at per project and per version, so for a per-person split you need an external report or an export. Capacity planning off these numbers is its own topic, but teams that measure their meeting share for the first time usually find it larger than they planned for.

Getting the numbers without typing them

The Community threads keep coming back because logging meetings means opening Jira six times a day, or rebuilding the week from the calendar on Friday. Every start time and duration is already in the calendar; you only have to add the issue.

This is what Planim Time does. Connect Google Calendar, Microsoft 365 or, on a Mac, Apple Calendar, with read-only access, and your meetings appear next to your worklogs. An issue key in the title is matched directly. Pick an issue for a meeting once and the app remembers it for that series and that title, so the daily standup goes to the ceremonies issue from then on without asking. Other meetings get keyword suggestions against your issues, and a default issue catches what is left. One click per meeting, or Log all for the day, and each one lands in Jira as a normal worklog with the real start time, the duration, and the meeting title as the comment.

Calendar events stay on your machine, and the Planim Time server is involved only in the sign-in. Private events are not read. The step-by-step, with the manual Log work procedure for comparison, is in How to log meeting time in Jira straight from your calendar.

A three-line team rule

Put it in the team's working agreement:

Ceremonies go on this sprint's ceremonies issue.
A meeting about a ticket goes on that ticket, with the meeting name in the comment.
Log it the same day, from the calendar, not on Friday from memory.

Google Calendar to Jira worklog: every way to get meeting time logged

Vladimir Letiagin — Sun, 01 Nov 2026 18:11:33 +0000

Half of what people search for under "Google Calendar Jira integration" goes the other way: putting Jira due dates and sprints on a calendar. This is about the opposite direction. You have a Google Calendar full of meetings, your team logs time in Jira, and at the end of the week none of those meetings exist in Jira.

That gap is bigger than most people think. Count the meetings in a normal week, multiply by their length, and you get a day or more that never became a worklog. The calendar already knows when each meeting happened and how long it ran. The only missing piece is which Jira issue it belongs to.

Here is what works, from the cheapest option up: by hand, a free Marketplace app, Tempo or Clockwork if you already pay for them, and Planim Time, which remembers the issue per meeting.

By hand, from the calendar

Open the event, note the start and the length. Open the issue in Jira, Log work, type the duration, change Date started from "now" to the meeting's start, paste the title into the comment. Save. Repeat for the next meeting.

It works, and for two meetings a week it is fine. Past that, nobody does it on the day. It becomes a Friday job, and Friday memory rounds everything to the nearest hour and attaches half of it to the wrong ticket.

A free Marketplace app, with one condition

There is a free app on the Atlassian Marketplace called Google Calendar Event to Worklog for Jira Cloud, by Move Work Forward. It reads your Google Calendar and offers events as worklogs. The condition is in the name of the event: it needs the issue key in the title, like PAY-412 refunds sync, otherwise it has nothing to attach the time to.

Its last release listed on the Marketplace is version 1.0.0 from October 2023, and it is Google only. A similar app, WiseLog, is marked unsupported.

Tempo and Clockwork, if you already pay for them

Both big Jira time-tracking apps have Google Calendar connections, and both come as part of the paid product rather than as a standalone feature.

Tempo Timesheets shows your Google events as cards in My Work. A card logs in one click when the event title contains the issue key; otherwise you pick the issue on each card. Private and "free" events are skipped, and the connection is one-way.

Clockwork connects Google and Outlook calendars in its Pro plan. You click an event, pick the issue, and the worklog is prefilled with the meeting's time. There is no key matching documented, so it is a pick per event.

If your organisation already runs one of these, the calendar part is in there.

Clockify and Toggl: calendar events as their own time entries

Both show your Google Calendar next to their own timer. Clockify has "Copy as time entry" on each event; Toggl can create a time entry automatically a few minutes after a meeting starts. The entries land in Clockify or Toggl, not in Jira. Their Jira integrations are browser extensions that put a start button on the issue page, and nothing moves a calendar event into a Jira worklog.

Planim Time: pick the issue once

Planim Time is a time tracker for Jira on Mac, Windows and Linux. It connects Google Calendar with read-only access, and meetings from the last 30 days and the next 7 show up next to your worklogs, in a calendar view and at the bottom of each day's list.

Here is how the issue gets picked. A key in the title still works. On top of that, once you pick an issue for a meeting, the app remembers it for that series and for other meetings with the same title, so the daily standup gets its ceremonies issue once and never asks again. Meetings with neither a key nor a memory get up to three suggestions by keyword match against your issues, and you can set a default issue for whatever is left. Each meeting shows the reason next to the issue. One click logs it, and Log all logs the whole day.

Events are downloaded straight from Google to your machine; the Planim Time server only brokers the sign-in. Private and confidential events are never read. The full walkthrough, including where meeting time should go in Jira in the first place, is in How to log meeting time in Jira straight from your calendar.

Four things to check before you pick

The direction. "Jira to Google Calendar" is a different product, and most search results are about that one.
Whether it needs the issue key in the event title. If it does, the whole team has to start naming meetings that way, or the integration covers only a fraction of your calendar.
Where the event titles go. Some tools store them on their servers, some keep them on your machine. Check the vendor's privacy page.
What lands in Jira. You want a worklog with the meeting's real start time and a comment; a time entry in another tool never shows up in Jira.

How to log Outlook and Teams meetings to Jira as worklogs

Vladimir Letiagin — Sun, 01 Nov 2026 18:10:58 +0000

Someone asked Atlassian Community in 2019 how to log time from an Outlook calendar appointment to Jira. People are still asking in 2025, on the Toggl forum too, and the answers have not improved much: a Tempo link, an Outlook add-in that has since disappeared, and "create a Meetings ticket".

The confusion starts with the word "integration". Atlassian's own Outlook add-in is about issues and email: create an issue from a message, see issue details in the sidebar. It does not log time. Most "Jira Outlook calendar" results are about getting Jira due dates and sprints into Outlook, again the wrong direction. What the question means is: I have an Outlook calendar full of Teams meetings, my hours live in Jira worklogs, how do I get one into the other. The options today are by hand, Tempo, Clockwork, and Planim Time connected to Microsoft 365; Toggl and Clockify show the calendar but stop before Jira.

The manual way, and why it fails

Open the appointment, note start time and duration. Open the issue, Log work, type 45m, set Date started to when the meeting began (it defaults to now, which is how worklogs end up claiming you were in the morning standup at six in the evening), paste the subject as the comment. Save.

For one meeting that is a minute. A week of them usually waits until Friday, and by then the times come from memory instead of the calendar.

Tempo, if your organisation runs it

Tempo Timesheets has a Microsoft 365 calendar connection. Your Outlook events appear as cards in My Work. Events with an issue key in the subject log in one click; for the rest you choose the issue on the card. Two things to know from Tempo's own docs: it works with Microsoft 365 in the cloud, not with on-premises Exchange, and an organisation-wide setup needs admin consent for the Tempo app in your tenant.

Clockwork, Toggl, Clockify

Clockwork connects Outlook calendars on its Pro plan. Choosing an event and then an issue gives you a worklog prefilled with the meeting's time.

Toggl Track and Clockify both show your Outlook calendar inside their apps, cloud Outlook only. Toggl can turn each meeting into a time entry on its own; Clockify has a "Copy as time entry" button. Those entries stay in Toggl or Clockify. Their Jira connections are browser extensions that add a timer button to the issue page, and there is no path from a calendar event to a Jira worklog. The Toggl community thread asking for exactly that has no answer.

Planim Time on Microsoft 365

Planim Time is a time tracker for Jira on Windows, Mac and Linux. It connects to Microsoft 365 through the standard Microsoft sign-in with read-only calendar permission (Calendars.Read), and from then on your Outlook events, Teams meetings included, show up next to your worklogs: in a week calendar and at the bottom of each day's list.

If the subject has an issue key, the meeting goes to that issue. When you choose an issue by hand, the app keeps the choice for the whole series and for meetings with the same subject, so recurring meetings stop asking. Anything left gets up to three keyword suggestions from your issues or falls to a default issue. Declined meetings, all-day events and slots marked free are skipped unless you turn them on. Each meeting logs with one click, and Log all logs the day.

Events go from Microsoft Graph straight to your computer; the server only handles the sign-in. Private and confidential events are not read. The full walkthrough is in How to log meeting time in Jira straight from your calendar.

What to decide before you connect anything

Where ceremonies go. Standups and planning need an issue, because every Jira worklog does. Most teams keep one ceremonies issue per sprint and log topic meetings on the issue they were about. Decide that before you connect a tool, so logging a meeting doesn't start with working out where it goes.

Who sees the meeting subjects. The subject of an internal meeting is often more sensitive than the hours. Read the privacy page of whatever you connect, and prefer tools that keep the events on your side.

How to log work in Jira for previous days: a whole week at once

Vladimir Letiagin — Tue, 13 Oct 2026 18:36:00 +0000

Friday, somewhere after four. The timesheet reminder lands in Slack, and the week in Jira looks like this: Monday logged, Tuesday logged, then nothing. Three days, maybe twenty hours of actual work, and the only record is whatever your memory kept.

Logging work for a previous day in Jira is easy enough: open the ticket, Log work, change the date. Logging three previous days across a dozen tickets is a different job, because first you have to remember what went where. Memory keeps very little. I've done this reconstruction enough times to know the pattern: you remember the big ticket you fought with on Wednesday, you forget the four small ones you closed before lunch, and the review you spent an hour on gets attached to the wrong day. The result looks like a timesheet, but half of it is fiction.

But you don't have to remember. Jira already wrote it down.

What Jira knows about your week

Every time you touch an issue, Jira keeps a timestamped record of it:

status changes (To Do, In Progress, Done), in the issue's History tab
every comment you wrote, with its creation time
field edits: assignee, priority, sprint, estimate, labels
issues you created

That's a pretty complete trail of which tickets you were on and roughly when. What it's missing is duration. Jira records that you moved a ticket to In Progress at 10:14 and commented on it at 11:50. It has no idea whether you worked on it for those ninety minutes or jumped to something else at 10:20.

So the realistic split is: activity gives you the issues and the order, you supply the hours. Pretending it's more precise than that is how reconstructed logs start reading like fiction again.

The manual version: one previous day at a time

You can do this by hand. Open Jira, search for issues you changed that week, and go through them one by one: the History tab shows when you moved it, the comments show when you wrote something. Lay the tickets out in order per day, drop the ones you only touched for bookkeeping (editing an estimate is not work), and give each one a rounded duration. Keep the day capped at the hours you actually sat there, so eight small touches don't add up to an eleven-hour log. Then log every entry with the date the work happened, not today's: the Log work dialog has a date field, it just defaults to now.

That works. It also takes forty minutes for three days, which is exactly why most people skip it and type "8h, misc" into one ticket instead. If you want the careful version of the method, with the exact search and the tricky cases, I wrote it up here.

The version I built instead: several days at once

I build a desktop time tracker for Jira called Planim Time. It's a menu-bar timer most of the time, but the part that matters for this post is a sidebar called Recent Work, which does the reconstruction above and puts the result on a calendar.

Here's what it does when you open a week that has gaps:

It pulls your trail. Through your own Atlassian account it fetches every issue you changed that week, with its history and comments. It keeps your status moves, comments, field edits and created issues, and throws away the bookkeeping: worklog edits, estimate changes, deleted comments.

It turns touches into blocks. Touches on the same issue that sit close together become one work session. The block starts at your first touch and runs to your last one, and it never crosses midnight or runs into the future. Each block carries a confidence level for where it sits on the clock: a session with a status change at the start and a comment at the end is "high", a single comment at 3 pm is "low" and you should treat the start time as a guess.

It refuses to invent time for bulk actions. If you moved six tickets to Done in ten seconds on Friday afternoon, that is not six work sessions. Those land in the sidebar as candidates with no duration. You can give one a duration if it was real work, or leave it. A ticket that was swept and had real activity that day keeps a single card.

It shows them on the calendar before anything is written. Suggestions appear as ghost blocks on the week grid, next to the worklogs you already have. You can drag one to another hour, resize it, reassign it to a different issue, or dismiss it. The sidebar and the calendar stay in sync, so what you see is what will be logged.

It keeps the day from overflowing. A capacity bar at the top shows logged hours plus proposed hours against your daily target. If suggestions sum past your target, the app trims them rather than letting Wednesday become a fourteen-hour day. The gap to your target stays visible as a gap, instead of being quietly absorbed into the last block.

Then one click. "Add all" creates a draft worklog from every timed block (candidates without a duration are skipped, on purpose). Push sends them to Jira as ordinary worklogs under your account, each dated to the day the work happened, so your Friday push doesn't look like you did the entire week on Friday.

Three days of gaps is a few minutes of looking at the ghosts and nudging the ones that are wrong. Mostly you're confirming durations, which is the one thing the data can't tell you anyway.

The better fix is upstream

Everything above is damage control. The cheap fix is to not have the gap in the first place, and a timer in the menu bar that writes a worklog with the real start time when you stop it does most of that. Idle detection (macOS and Windows) catches the "left the timer running through lunch" case. Recent Work is for the days when you forgot to start it at all, which, for me, is still about one day in ten.

Planim Time runs on macOS, Windows and Linux. It's on the Atlassian Marketplace and at time.planim.app. If you've got a reconstruction trick that works better than reading the issue history, I'd like to hear it in the comments; the sidebar started as exactly that kind of trick.

Jira can't move a worklog to another issue, so we put worklogs on a calendar

Vladimir Letiagin — Mon, 17 Aug 2026 11:00:00 +0000

Last Friday I found 3h 20m logged on PROJ-1417, a ticket I'd touched for about five minutes. The actual work went into PROJ-1423, which showed zero. No problem, I thought, I'll move the worklog.

Turns out you can't. Jira has no "move worklog to another issue". There's no button in the UI, and the REST API doesn't have the operation either. I build a time tracker for Jira for a living, and this one still gets a "wait, seriously?" from almost everyone I tell.

What Jira expects you to do instead: open the entry, write down the duration, the start time and the comment somewhere, delete it, open the correct ticket, and type everything back in through the Log work dialog. If you get distracted halfway through, that's it. Worklogs have no undo and no recycle bin.

Why there's no move button

A worklog is a tiny record: seconds spent, start timestamp, comment, author. Notice what's missing: an issue field. The issue is the address of the worklog (it's literally in the API path, /rest/api/3/issue/{key}/worklog/{id}), not one of its properties. There's nothing to edit. Any "move", in any tool, can only be a copy created on the destination plus a delete at the source. Jira simply doesn't offer to run the pair for you.

Knowing this doesn't make the manual version less annoying, but at least it stops looking like an oversight. It's structural.

Wrong-ticket time comes in batches

Something we learned from our own support inbox: misfiled worklogs almost never arrive one at a time. There's always a systematic cause. The timer kept running on the old ticket after a task switch, so the whole afternoon landed wrong. The hours went to the story when the sub-task was the actual work. Or two client projects have near-identical keys and autocomplete guessed wrong all week.

Each of those gives you five or ten bad entries in one go, and the delete-and-retype ritual is per entry. Realistically, nobody spends their Friday on that. The entries stay where they fell, the project totals are off, and whatever reads those totals (reports, invoices) is off too. Jira makes it worse by having no screen where you'd even notice: there's no view that shows all your worklogs in one place, so a misfiled entry stays invisible unless you go digging through the Work log tab of a ticket you don't suspect.

So we put the week on a calendar

Our tracker is called Planim Time, a desktop time tracker for Jira that lives in the menu bar. The part that matters for this post is the calendar: every worklog is a block on a week grid, sitting at its start time, with the issue key on it. Height is duration.

Once your week looks like that, misfiled time stops being a search problem. The bad entry is just... sitting there. Wrong key, plain sight.

And each way an entry can be wrong turns into a direct manipulation:

wrong issue: click the block, search for the right ticket, confirm. Duration, start time and comment travel with it
wrong day or time: drag it where it belongs
ran too long because you forgot to stop the timer: grab the edge and shrink it

Everything writes back to Jira as ordinary worklogs, through your own account. Sync is two-way, so entries you created in Jira's own dialog (or in any other tool) show up on the calendar too and can be fixed the same way. Wrong day and wrong duration have a few extra wrinkles of their own; we wrote those up separately in a guide to changing logged hours in Jira.

To be clear about what happens underneath: Jira still has no move, so on "confirm" the app creates the copy on the new issue first and deletes the original after. Worst case, a crash between the two leaves you a duplicate for a moment. The manual ritual's worst case is the entry existing only in your memory.

The limits are Jira's rules, not ours: you can only move worklogs you authored (the API has no way to write a worklog as someone else), and you need worklog permissions on both projects.

Doing it by hand anyway

Maybe a stray worklog happens to you twice a year and installing anything is overkill. Fair. Then at least flip the order of the official procedure: log the time on the correct issue first, with the original date in the Date started field, check it saved, and only then delete the entry from the wrong ticket. Create first, delete second. Nothing ever exists only in your head. The full walkthrough, permission names and estimate prompts included, is in our post on moving a Jira worklog to another issue.

The tracker itself is free to try: macOS, Windows, Linux, signs in with your Atlassian account. Tracking and two-way sync are on the free tier; the calendar is a Pro feature with a 14-day trial. If your Fridays regularly include archaeology on your own worklogs, you'll know within a week whether the calendar earns its keep.

Forgot to log your time in Jira again? Your activity already remembers.

Vladimir Letiagin — Wed, 24 Jun 2026 13:58:40 +0000

There is a specific kind of dread that arrives on Friday afternoon. The timesheet is due, you open Jira to log your week, and Tuesday is blank. Wednesday is mostly blank. Your memory of the last five days is three meetings, a bug that ate a morning, and a general sense of having been busy. So you start guessing. Everything becomes "probably two hours," you round until the day adds up to something believable, and you quietly hope nobody ever audits it.

If that feels familiar, you are not bad at your job. You are just doing a job that involves jumping between five tickets, three Slack threads, and the occasional production fire, none of which leave you in a calm state to remember a timer.

Timers assume a workday you do not have

This is the part nobody admits about time tracking. A timer assumes you will press start the moment you begin a task and stop the moment you finish. On a quiet day, fine. On a real day, you forget within the hour, the timer is still running on a ticket you closed before lunch, and by Friday it has captured maybe a third of your actual week. The tool that was supposed to rescue you from guessing has left you guessing anyway, just with extra steps.

So most people give up on the timer and go back to reconstructing the week from memory. Memory is the worst possible source. It is exactly the thing the whole exercise was meant to avoid.

You do not need to remember. Jira already wrote it down.

Here is the reframe that fixed this for me. You do not actually have to remember your week, because Jira has been keeping notes the entire time. Every ticket that got assigned to you, every issue you commented on, every status you dragged from In Progress to In Review, all of it is recorded with a timestamp. Put together, that is a near-complete log of what you worked on. It is just scattered across issues instead of sitting in a tidy timesheet.

So the honest way to fill a blank week is not to squeeze your memory until something comes out. It is to read your own activity back and turn it into worklogs. Your activity tells you which tickets you touched and roughly when. You supply the one thing it can never know, which is how long each one actually took.

You can do this entirely by hand: open each issue you touched, check its history and your comments, drop it onto the right day. If you like that sort of thing, I wrote a longer, more technical walkthrough of the manual version over here. It works. It is also tedious enough that most people try it once and quietly go back to guessing.

The version that does the digging for you

Quick disclosure before this next part: I am on the team behind Planim Time, so take the recommendation with that in mind. We built it because we kept losing our own Tuesdays.

Planim Time is a small menu-bar app for tracking Jira time. The feature that matters for the Friday scramble is Recent Work. It reads your recent Jira activity, the issues you were assigned, commented on, created, or moved, and turns them into suggested worklogs. They appear as blocks on a calendar, sitting roughly where you touched them during the day. You drag to set the length, a capacity bar keeps a dozen small touches from quietly adding up to an eleven-hour day, and once it looks right you push the whole week to Jira in one click.

It does not pretend to know your durations, because nothing can. Jira records when you touched a ticket, never for how long. What the app removes is the archaeology. Instead of rebuilding Tuesday from a blank page, you start from a draft that is already mostly right and just correct the hours.

A few things we were deliberate about, since you have probably been burned by a tracker before:

It lives in your menu bar, not a browser tab you forget to open.
It works offline and writes worklogs straight onto the Jira issue, so no separate cloud is holding your hours hostage.
No screenshots, no keystroke monitoring, none of that.
The free tier is a complete tracker, not a countdown to a paywall.

Stop guessing your timesheet

If the end-of-week scramble is a recurring feature of your life, it is worth ten minutes to try a different approach. You can grab Planim Time at time.planim.app, point it at your Jira, and let it show you what you already did this week.

And if you would rather keep the whole thing manual, the longer guide has the queries to do it yourself. Either way, the takeaway is the same: stop interrogating your memory on Friday. Your activity already knows the answer, you just have to read it back.

The best Jira time trackers for engineering teams in 2026

Vladimir Letiagin — Tue, 12 May 2026 19:48:53 +0000

Prices in this category move. Re-verify before quoting any number internally.

Criteria

What I'm not weighing, and what I am.

I don't weigh mobile apps highly for this audience. Phone-first tracking matters for field service, agencies billing from cafés, consultants on the move; Clockify below earns its spot partly on that. For an engineer in a sprint at a two-monitor desk, it's almost never the deciding factor.

I don't weigh AI weekly summaries highly. They're the headline feature on every tracker's pricing page right now, and the engineers I talk to read them once and turn them off. The hour you logged on Tuesday is whatever the worklog says.

I do weigh:

Survival of a Jira outage. Atlassian's status page shows a couple of degraded periods most months. If your tracker goes blank during them, that's a failure mode you keep paying for.
Where the API token lives. OS keychain means it shares a vault with the saved passwords in your browser. SaaS account means you inherit that vendor's threat model.
Round-trip sync, not just push. When a teammate fixes a worklog directly in Jira, your tracker either picks that change up or silently overwrites it on the next push. Most overwrite. I've written about why separately.
Whether you need a Jira admin to install it. Marketplace apps need one; desktop apps don't. For a single engineer trying to evaluate something, the difference between five minutes and three weeks of internal tickets is decisive.
Free tier that isn't a teaser. An indefinite free tier that does the job, or a long trial. "Fourteen days then it nags you" doesn't count.

Tempo Timesheets: finance and PMO that doesn't sleep

If someone at your company has "Director" in their title and reads timesheets monthly, Tempo Timesheets is probably already the answer. It's been the #1 time-management product in the Atlassian ecosystem since 2009, and the feature stack shows it: approvals, capacity planning, budgets, invoice-ready timesheets, audit-friendly reports. None of which is easy to retrofit.

Tempo Timesheets on Cloud starts at $10 per user per month and scales per Jira user from there. List prices have crept up roughly once a year, so before quoting any number, re-check the Marketplace listing.

Trade-off: you're paying per Jira user for a workflow that mostly serves the finance side of the room. A four-engineer squad paying $40/month so two of them log hours and a non-engineer runs an approval flow stops liking enterprise features pretty quickly. That's the gap I see most when teams leave Tempo. Tempo isn't bad; the engineers were paying for a finance product they didn't need.

Pick Tempo if approvals, capacity planning, or client invoicing inside the tracker are load-bearing for your team. We have a longer head-to-head if you want the row-by-row.

Clockwork: free for ten, Jira-internal for everyone else

Clockwork (HeroCoders) is the lightest option in the Marketplace. Two SKUs: Pro, free for ≤10 Cloud users and paid above, and Lite, which HeroCoders split off in January 2025 for teams that want something smaller and cheaper than Pro.

Under ten Cloud users, this is hard to beat: a real timesheet UI, embedded inside Jira, at zero cost. The catch is the same as Tempo's at smaller scale. The timer is a Jira widget that lives or dies with the page. No offline mode, no menu-bar surface.

Watch the upgrade cliff. Above ten users the per-Jira-user model bills every Jira user, including ones who'll never log an hour. A 50-person org where 12 actively track ends up paying for 38 people who don't.

Pick Clockwork if you want a free timesheet that lives inside the Jira tab itself (no separate app to install) and your team is ≤10 users on Cloud, or your policy is "everything stays in Jira's database". Head-to-head.

Everhour: when the timer also has to be the invoice

Everhour is the right pick when "track an hour" and "bill a client" are two faces of the same job. Pricing as of April 2026 is $8.50 per user per month billed annually, with a 15% premium for monthly billing and a five-seat minimum on the paid plan. The free tier covers up to five users.

The Jira integration is a Marketplace add-on that replaces Jira's native time-tracking UI with Everhour's controls (with an optional browser extension for list and board views). Projects sync into Everhour's web dashboard, and that's where the centre of gravity is: budgets, billable rates, custom reports, QuickBooks/Xero/FreshBooks integrations, capacity planning. If a single hour has to end up on a client invoice through the same tool that started the timer, Everhour has built around that opinion for years.

The engineering trade-off: you pay for an invoicing engine even if you never invoice, your token lives in Everhour's cloud (not your OS keychain), and logging forty minutes against PROJ-1247 takes more clicks than it should.

Pick Everhour if you bill clients hourly and the tracker also has to be the billing system. Head-to-head.

Clockify: generalist with a phone in its pocket

Clockify is the breadth play. The free tier covers up to five users and includes a working timer, timesheets, idle detection, calendar view, mobile + desktop apps, Pomodoro, kiosk mode, and 80+ integrations. Paid tiers run Basic $4.99 / Standard $6.99 / Pro $9.99 / Enterprise $14.99 per user per month, with ~20% off on annual. The Jira integration pushes worklogs through the browser extension.

If your tracking life really does span Jira, GitHub, Trello, Asana, Basecamp, ClickUp plus a phone, that breadth is paid for and used. If 90% of your hours are on Jira, you're paying for surface you'll never touch. The Jira integration is also one-way (extension → Jira), not round-trip, so the moment a teammate fixes a worklog in Jira, the tracker goes quietly out of sync.

There's also the second-cloud problem: time entries live primarily inside Clockify and get pushed to Jira on demand. For an engineering team that already pays Atlassian for Jira, a parallel store of the same data is something a security review will eventually flag.

Pick Clockify if you track across many tools or you need a mobile app as a first-class surface. Head-to-head.

Planim Time:

Planim Time for Jira It's a native desktop app, a menu-bar or system-tray icon on macOS, Windows, and Linux. It talks to your Jira instance through your personal API token, stores the token in the OS keychain, and runs entirely offline. Worklogs sync both ways: edit one in Jira's UI and it shows up in the tracker within about a minute, no webhook server in the middle. Issue selection is JQL-driven, so whatever filter you already use in Jira, the tracker can use too.

On a normal workday the surface most people live in is the calendar (Pro). It's a multi-week grid where worklogs are draggable blocks you can resize to extend or shorten. Closer to how Google Calendar feels than a row-by-row spreadsheet. Team stats roll up every member who logged time to the workspace's Jira issues, not only the paid seats, so the boards include everyone's hours without you having to buy licences for the people who won't use Pro. Both come with a 14-day trial on first launch, no card.

Where Planim Time loses to the four above: no approval workflows, no capacity planning, no budgets, no full invoicing (CSV export is as close as we get), no mobile app, no kiosk mode. We track worked hours and push them to Jira; everything else is somebody else's job. If you need any of that, one of the four above will earn its seat. We wrote separately about why we shipped a desktop binary instead of a Marketplace plugin if you want the architectural side of that trade-off.

Pick Planim Time if Jira is your source of truth, you want a timer that survives both Jira outages and laptop tab-evictions, and you'd rather your API token live in the OS keychain than in another vendor's cloud.

The short version

Finance reads your timesheets monthly? Tempo Timesheets.
You want the timer to live inside the Jira tab itself, ≤10 users on Cloud? Clockwork (Pro Free or Lite).
You bill clients hourly through the same tool that runs the timer? Everhour.
Your tracking life spans many tools and you need a real mobile app? Clockify (free up to five users; $4.99–$14.99 per seat above that).
Jira is the source of truth and you want a timer that survives Atlassian's bad afternoons? Planim Time.

Five buckets, five different winners. There isn't a single "best Jira time tracker", and the mistake every other roundup makes is pretending there is one.

If you've got Jira and an hour you need to remember on Tuesday, download Planim Time and point it at your real instance for a sprint. If it doesn't earn its keep in the first week, one of the four above will, and now you know which one.

Building a Jira Time Tracker with Tauri: How I Stored API Tokens Securely

Vladimir Letiagin — Wed, 29 Apr 2026 18:49:08 +0000

I've been building a small menu-bar app for tracking time on Jira issues. Mostly it's boring CRUD: a timer, a list of issues, push worklogs back to Jira. Except for one thing I had to figure out on day one. The user logs in with a Jira API token, and that token has to live somewhere on their machine.

Where, exactly?

Every Tauri tutorial skips this part. Below is what I tried, what broke, and what I shipped.

My first attempt (don't do this)

I already had a local SQLite database in the app for caching Jira issues, worklogs, and user prefs. So my first move was the obvious one — stick the API token in a settings table next to everything else. One database, one place to look, simple.

Don't do this.

SQLite stores everything in a plain .db file on disk. No encryption by default. Anyone with file access on the machine reads your token in two seconds:

sqlite3 app.db "SELECT value FROM settings WHERE key='api_token'"

Backups, iCloud sync, Dropbox, malware scanners — all see it. Same problem with localStorage in the Tauri webview, with a JSON file in the app data dir, or with convenience plugins like tauri-plugin-store. Plain text on disk is plain text on disk. And if your frontend has any XSS-shaped bug, the token is right there for a script to grab.

What you actually want is the OS credential store. Every desktop OS ships with one. They exist specifically to keep secrets off plain disk and away from other users on the machine.

What Tauri suggests

Tauri's official docs point you at the Stronghold plugin. It uses IOTA's Stronghold engine, encrypts everything with a password, and writes to a snapshot file.

Stronghold solves a different problem — a full vault with key derivation, multiple records, the whole deal. For a single API token it's the wrong shape. It also needs the user to enter a password to unlock the vault, or you stash that password somewhere, and now you've moved the problem one level up. Where do you store the password that unlocks Stronghold?

I wanted the OS to handle the trust. That means the system keychain.

What I actually used: the keyring crate

The keyring crate is a Rust wrapper that gives you one API on top of:

macOS: Keychain Services
Windows: Credential Manager
Linux: Secret Service API (gnome-keyring, KWallet, etc.)

You write the code once, and on each platform it talks to the native store. Users get the same security guarantees they expect from Safari saving a password or git saving a credential.

Heads up: keyring 3.x is a major bump from 2.x with breaking API changes. Half the tutorials you'll find on Google are still on the old version, so check the version in their Cargo.toml before copy-pasting.

Cargo.toml:

[dependencies]
keyring = { version = "3", features = [
    "apple-native",
    "windows-native",
    "sync-secret-service",
    "crypto-rust",
] }

Those features matter. apple-native and windows-native use the platform APIs directly. sync-secret-service is the Linux backend. crypto-rust handles the D-Bus transport encryption in pure Rust so you don't drag in an OpenSSL dependency.

The whole storage module

This is the entire secure_store.rs from my app. There's nothing more to it:

use keyring::Entry;

const SERVICE: &str = "planim-time-tracker";

pub fn set_secret(key: &str, value: &str) -> Result<(), String> {
    Entry::new(SERVICE, key)
        .map_err(|e| format!("Keyring entry error: {e}"))?
        .set_password(value)
        .map_err(|e| format!("Failed to save to keyring: {e}"))
}

pub fn get_secret(key: &str) -> Result<Option<String>, String> {
    match Entry::new(SERVICE, key)
        .map_err(|e| format!("Keyring entry error: {e}"))?
        .get_password()
    {
        Ok(v) => Ok(Some(v)),
        Err(keyring::Error::NoEntry) => Ok(None),
        Err(e) => Err(format!("Failed to read from keyring: {e}")),
    }
}

pub fn delete_secret(key: &str) -> Result<(), String> {
    match Entry::new(SERVICE, key)
        .map_err(|e| format!("Keyring entry error: {e}"))?
        .delete_credential()
    {
        Ok(()) | Err(keyring::Error::NoEntry) => Ok(()),
        Err(e) => Err(format!("Failed to delete from keyring: {e}")),
    }
}

Three functions, no state, no init. The SERVICE constant is what shows up as the entry name in Keychain Access on macOS or Credential Manager on Windows. Pick a stable name and don't change it later — if you do, every existing user loses their saved credentials and has to re-auth.

One thing worth being explicit about: this is for secrets only. Tokens, refresh tokens, passwords. User preferences, base URLs, UI state — that all goes in SQLite or wherever else makes sense. Keychain entries are slow-ish to read and have size limits, so don't dump everything in there.

Wiring it into a Tauri command

I never touch secure_store from the frontend. The frontend asks for an action, the backend handles the secret. The Jira API token never leaves the Rust side once it's saved:

#[tauri::command]
pub async fn settings_save_jira_config(
    state: State<'_, AppState>,
    base_url: String,
    email: String,
    api_token: String,
) -> Result<(), String> {
    // non-secret fields go in SQLite
    // ...
    secure_store::set_secret("jira_api_token", &api_token)?;
    Ok(())
}

The pattern: secrets in keyring, everything else (Jira base URL, email, preferences) in SQLite. The frontend never holds the token in JS state for longer than a single form submission.

Per-OS gotchas you'll only find out about in production

This is the part nobody mentions until it bites you.

macOS

The first time another binary tries to read a Keychain item, the user gets an "allow access" prompt — three buttons: Always Allow, Allow, Deny. No password input. A lot of devs avoid Keychain because they think it nags users for their macOS password every time. It doesn't, as long as you put items in the login keychain (which is what keyring does by default). The login keychain is unlocked automatically when the user signs into the Mac, and stays unlocked.

The catch: Keychain identifies your app by its code signature. If the signature changes, Keychain treats it as a new app and prompts again. In development, every cargo build produces a new ad-hoc signature, so you see the "allow access" prompt after every rebuild. Annoying, but it goes away in production as long as you sign with a stable Developer ID. The signature stays consistent across app updates, and Always Allow sticks.

If you ship unsigned, you have a bigger problem than Keychain prompts: macOS 15+ makes it deeply painful for users to launch your app. The right-click → Open trick is gone in Sequoia — users now have to dig into System Settings → Privacy & Security and explicitly allow the binary every time. Sign your app. The Apple Developer Program is $99/year and worth it for any real desktop app.

Notarization, by the way, doesn't affect Keychain at all. That's only for Gatekeeper letting users open downloaded .dmg files.

There's also a quirk where if you change your bundle identifier or developer team, Keychain treats the new build as a different app. Pre-existing entries from old builds stay in the user's Keychain forever unless you clean them up. On uninstall, run delete_credential for every key your app stores.

Windows

Credential Manager is per-user. No prompt at all, ever. Items are protected by the user's Windows login. Easy mode.

The catch: if a user logs into Windows with a different account, they don't see those credentials. Which is what you want, but it occasionally confuses users with multiple Windows accounts on the same machine.

Linux

This is where it gets messy. The Secret Service API needs an active D-Bus session and a running provider, usually gnome-keyring-daemon or kwalletmanager. On a clean GNOME or KDE desktop, no problem. On a minimal i3 or sway setup, or in a CI container, there's no daemon running, and keyring returns an error.

I handle that case explicitly. If the keyring lookup fails on Linux, I show the user a message asking them to install gnome-keyring. Most desktop users won't hit it, but power users on bare WMs will, and silently failing is the worst possible UX.

For headless or server use, the keyring crate has a mock feature for tests, and there are file-based fallbacks. I didn't ship those because the app is desktop-only.

What I'd skip if I started over

A few things I tried first and threw away:

Encrypting a JSON file with a hardcoded key in the binary. Anyone with a hex editor pulls that key out. Pointless.

Stronghold. Not because it's bad — it's a serious piece of crypto engineering. But for a single API token, it added a password-unlock flow my users didn't want. They expected the OS to remember them, the way every other app does.

See it in production

The app I built on top of all this is time.planim.app. One-click timers on Jira issues, automatic worklog sync, calendar view, custom JQL filters — all without leaving the menu bar.

If you went the Stronghold route, or built some hybrid setup, or solved this differently on Linux — drop your approach in the comments. Curious what trade-offs other people made.

P.S. — if you're shopping around for a Jira time tracker rather than building one, I followed up with a comparison of how five different
products handle this same problem — Tempo, Clockwork, Everhour,
Clockify, and Planim Time. Same threat-model lens, applied to the rest of the category, with the actual auth model each one uses.