Time tracking in Jira: logging work, Tempo, and simpler alternatives

Development work has been in Jira for years. Estimates go on the issues, work gets logged, burndown looks reasonable. Then someone outside engineering asks a different question: how many hours went to this client last month, who signed off on them, and which of those hours are billable. The data feels like it should already be there, and it almost is. It is just in a shape that answers a different question.

Jira does have time tracking built in, and it is more capable than many people realise. It is also built around the issue rather than around the week, and that single design decision explains most of what teams run into next.

What Jira tracks out of the box

Atlassian's documentation describes three fields on an issue: original estimate, time spent, and remaining estimate. The first is set when the work is planned, the second accumulates as work is logged, and the third is what a person believes is still to come.

Logging happens on the issue itself, through More actions and Log work. Entries are typed in Jira's duration format, using weeks, days, hours and minutes, so an entry can read 2d 4h 30m. A bare number with no unit falls back to a default unit that a Jira administrator sets.

Several practical details are worth knowing before designing a process around it.

Time tracking has to be switched on. It is an administrator setting. If the fields do not appear on issues, that is why.

Editing and deleting work logs is permission controlled. Atlassian lists separate permissions for editing own work logs, editing all work logs, deleting own work logs and deleting all work logs. Which of those are granted determines whether a logged hour is a note or a record.

There is a limit on rolling up children. Atlassian's documentation states that if a work item has more than 100 child work items, those children cannot be included in time tracking. Teams with very large epics hit this.

Used as designed, this is a genuinely useful system. It answers how long an issue took against what was estimated, and it does so without anybody maintaining a separate project list, because the issue is the project record.

Estimates and logged time are two different habits

Teams often enable time tracking and then use only half of it. Original estimates get filled in during planning because planning is a meeting with a deadline. Time spent gets logged sporadically, because logging is an individual habit with no deadline at all.

The result is a set of issues with estimates and no actuals, which looks like data and answers nothing. Before adding any app to this, it is worth checking which half is actually being filled in. If time spent is missing on most closed issues, the problem is the entry habit, and buying a timesheet product will reproduce it with a larger bill attached.

Where the worklog model stops short

The gap opens the moment the question changes from work to people.

An invoice is built from a period, not from an issue. Payroll is built from a person and a week. Contractor payments need a rate and a contract type. None of those axes exist in a worklog, which knows who logged the time and against what, but nothing about what an hour is worth or whether a period is finished.

Five things are commonly missing for a team that has to bill or pay from this data.

• A period view. Hours by person by week, in one grid, rather than scattered across issues.
• Submit and approve. A worklog can be entered and edited. There is no built in moment where a week is declared finished and someone signs it off.
• Rates and a billable flag. Internal rework on a fixed fee project is real time that should not appear on an invoice, and the worklog has no field that makes that distinction.
• Work with no issue. Sales calls, recruitment, internal meetings and admin are real hours. Creating a catch all issue works, but it is a workaround, and teams that do not do it end up with logged hours that are consistently lower than hours actually worked.
• Contract types. Hourly, per project and fixed monthly arrangements need different treatment at invoice time.

None of this is a flaw in Jira. It is a product built for tracking software work, and the worklog serves that purpose. The mismatch appears when the same data is asked to do finance work.

The Tempo route

The usual answer inside the Atlassian ecosystem is a Marketplace app, and the best known is Timesheets by Tempo.

Tempo's own product page describes a timesheet period that people log into and then submit for review and approval, usually by a team lead or manager. It describes tracking billable hours so that hours billed to clients can be compared against costs, and a set of reports covering timesheets, time spent, burn up and financial categorisation. It sits on top of Jira's existing worklogs rather than replacing them, so hours logged on an issue still exist as worklogs.

That is a direct fit for the five gaps above, which is why it is so widely used. Two things to weigh before adopting it.

It is a second subscription, priced separately from the Jira seat. The comparison to run is the per person total of both, not the price of either alone. Confirm current pricing on the Marketplace listing, since app pricing changes and often steps by user tier.

It adds a layer that people outside engineering have to learn. For a finance person or an account manager, the mental model becomes Jira plus an app inside Jira. That is fine at fifty people. At eight, it is a lot of surface area for a monthly invoice.

There is a third consideration that only appears later. An app that reads and writes Jira worklogs is tied to the Jira instance, so any future decision about the issue tracker is also a decision about the timesheet history. Teams that later consolidate tools discover that several years of billing records live inside an app inside a product they are leaving. That is solvable with an export, but it is worth knowing at the point of adoption rather than at the point of migration.

Three routes, and who each fits

Route	What it gives	What it costs	Fits
Built in worklogs only	Estimate against actual, per issue	Included	Teams whose question is delivery, not billing
Worklogs plus a timesheet app	Periods, approval, billable hours, reports	Jira seat plus app seat per person	Teams billing clients who want to stay in Jira
A tool that carries boards and hours together	One place for planning, hours and approval	One subscription	Small mixed teams where non engineers also need the data

The third route deserves consideration specifically when the people who need the hours are not the people using Jira. A small agency where two developers work in Jira and everyone else works in boards and chat is paying for a lot of issue tracker in order to produce a timesheet. Side by side pages such as the comparison list show which board tools carry hours themselves rather than delegating them to an app.

The first route is underrated. If the real question is whether estimates are accurate, built in worklogs answer it and nothing else needs buying.

Questions to settle before adding an app

Whichever app is chosen, the same four questions decide whether the result is trustworthy a year later.

Who counts as a user? Per seat pricing usually counts anyone who can log time, and sometimes counts people who only approve or only read reports. For a team of six doers and two approvers, the counting rule changes the bill by a third.

What happens to hours when issues are restructured? Epics get split, projects get archived, issues get moved between projects. Hours belong to a period as well as to an issue, and last quarter's report should not change because this quarter's board was reorganised.

How is non issue work recorded? If there is no answer, the gap between hours logged and hours worked will grow, and every per project cost figure will be understated by the same invisible amount.

Can a period be locked? An approval that can be edited afterwards is not an approval. Whatever is used to produce an invoice needs to be readable, unchanged, months later when the invoice is questioned.

A fifth question is about exit. Hours accumulate for years and become the basis of quotes, disputes and audits, so it matters whether they can be exported in full, with the person, the date, the project and the billable flag intact. Data that can only be read through one vendor's reports is data the team does not really own. Testing a full export during the trial takes a few minutes and is the cheapest insurance available.

When the simplest answer is a smaller stack

There is a version of this problem that does not need solving inside Jira at all.

Teams that adopted Jira for software delivery often find that only part of the company lives there. Designers, account managers, writers and contractors work in boards, documents and chat. When those people also need to record hours, putting them into an issue tracker plus a timesheet app is an expensive way to collect a number.

The test is who needs to enter hours. If it is only the engineers, a Jira based answer is the shortest path and the worklog data is already there. If it is everyone, then the timesheet needs to live where everyone already works, and the requirement becomes a project list shared with boards, a weekly grid, contract types and an approval trail. The features overview shows one arrangement where boards, chat and a weekly timesheet share a single project list, and the guide covers how hourly, per project and fixed monthly contracts are set up.

Whichever direction, run it on one real project for a month before rolling it out. The only thing that determines whether time tracking works is whether people fill it in, and a month of real entries answers that faster than any evaluation checklist.

What to change first

Check whether time tracking is even enabled in the Jira instance, and who holds the permissions to edit and delete work logs, since that determines whether logged hours count as a record at all. Then decide whether the question is estimate accuracy, which the built in fields already answer, or billing, which needs periods, rates and approval. If the people who need to record hours are mostly outside engineering, Pinateca is free for up to 5 people with timesheets available as an add-on.

Q1. Does Jira have time tracking without a plugin?

Yes. Atlassian's documentation describes original estimate, time spent and remaining estimate fields on work items, with hours logged through More actions and Log work in a format such as 2d 4h 30m. Time tracking has to be enabled by a Jira administrator first, so if the fields are not visible that is the usual reason.

Q2. What does Tempo add that Jira does not have?

Tempo's product page describes timesheet periods that employees submit for review and approval, billable hours compared against costs, and reports covering timesheets, time spent and financial categorisation. It builds on Jira's existing worklogs rather than replacing them. Those period, approval and billing layers are what the built in worklog does not provide.

Q3. Is Jira free, and how many people can use it?

Atlassian's pricing page lists a Free plan for up to 10 users, with paid plans above that. Marketplace apps such as timesheet products are billed separately from the Jira subscription, so a team using both is paying two per person amounts.

Q4. Why do Jira worklog totals come out lower than hours actually worked?

Because worklogs attach to issues, and a working day contains hours that have no issue: meetings, support, recruitment, admin and helping other people. Teams either create catch all issues for that work or accept a permanent gap. If the gap is not closed, every per project cost figure derived from worklogs is understated.

Q5. Can worklogs be edited or deleted after the fact?

That depends on permissions. Atlassian lists separate permissions for editing own work logs, editing all work logs, deleting own work logs and deleting all work logs. If everyone can edit their own logs indefinitely, the data is a working note rather than an auditable record, which matters as soon as it is used to produce an invoice.