Jira Software Time Tracking: What It Records and What It Misses

A client asks how many hours went into the January work. The board has three hundred closed items, the Time Spent column is populated on about half of them, and the totals do not resemble anyone's recollection of the month. The fields were there the whole time. Nobody agreed on what they meant.

This is the usual shape of the problem. Jira does record time, and the recording is more configurable than most teams realise. What it does not do is make people log consistently, or turn what they logged into something a finance team can use. Knowing exactly where the built in feature stops is the difference between a week of configuration that fixes the problem and a week that produces a tidier version of the same mess.

The three numbers Jira keeps

Time tracking in Jira Cloud is built around an estimate and a running total of logged work. The estimate goes in the Original estimate field. Every time somebody records work, that entry becomes a work log, and the sum of the work logs is the time spent. The remaining estimate moves as logs are added, and the panel on the work item shows the logged total against what is left.

Durations are entered in weeks, days, hours and minutes, written as w, d, h and m. An estimate can be 3w, and a log can be 2d 4h 30m. This is where the first silent error appears. If somebody types a bare number with no unit, Jira applies the default unit set by the administrator, which may be minute, hour, day or week. A team that types 2 meaning two hours, on a site where the default unit is day, has been overstating that work by a factor of eight, and nothing on the screen announces it.

Which field the estimate lands in is not fixed either. The estimation method for a board can be Original estimate, work item count, or a custom method, and story points are available for stories and epics in software spaces. A team estimating in story points and logging time in hours has two unrelated numbers on the same item. That is a legitimate setup, since points measure sizing and logs measure elapsed effort, but a report comparing them will produce nonsense.

One structural limit is worth knowing before a hierarchy is designed around rollups. If a work item has more than 100 child items, those children cannot be included in its time tracking, and Atlassian's documentation recommends keeping to a limit of 100 children per item. Large epics with hundreds of tickets underneath them will not total correctly.

The settings that decide whether the totals mean anything

Four global settings do most of the damage when they are left at whatever they were. They sit in the time tracking section of Jira administration.

Setting	What it controls	Why it goes wrong
Working hours per day	How many hours one logged day equals	A day still means eight hours on a site where nobody works eight
Working days per week	How many days one logged week equals	A five day default silently converts part time schedules
Time display format	Whether Time Spent reads as Pretty, Days or Hours	Days format hides that the underlying number is hours
Default unit	The unit applied when nobody types one	Turns 2 into two days on a site set to day

Both the hours per day and days per week values accept decimals, which matters for teams where a working day is genuinely seven and a half hours. Setting them correctly is the only way a logged 1d converts into the same number of hours that payroll uses.

Two further settings are easy to miss. The Original estimate field can only be filled in during creation or editing if the Time tracking field has been added to the screens associated with those operations, which is why some teams conclude the feature is missing when it is simply not on the form. And there is a setting that restricts who can see user time log entries to a chosen role or group. Disabled, individual time logs are visible to anyone who can see the item. That is a reasonable default for a small colocated team and an uncomfortable one the moment contractors and staff share a board.

Who can log, and who can quietly change the record

Logging work requires the Work on work items permission in the space. Without it, the fields are visible and the log action is not available, which reads to the person as the feature being broken.

Editing a log is a separate grant. Changing a work log needs either Edit own work logs or Edit all work logs, and deleting needs the matching delete permission. This matters more than it sounds, because a monthly total that will be invoiced should not be editable by everyone who can log against it.

Jira does keep a record. When a time log entry is edited or deleted, the previous values are retained rather than overwritten. Deleting a log also raises a decision about the remaining estimate: Jira can add the deleted time back automatically, or the remaining estimate can be set manually. Teams that delete logs without thinking about that second choice end up with remaining estimates that drift away from anything real.

The practical configuration for a team that bills is narrow. Give everyone Work on work items and Edit own work logs, keep Edit all work logs with the two or three people who close the month, and decide deliberately whether individual logs are visible to the whole space.

What it does not do

Four gaps account for most of the frustration, and none of them is a configuration problem.

It does not create the habit. The documented flow is to open an item, choose Log work, and enter a duration. That is a deliberate act, performed after the fact, competing with everything else at the end of a day. Teams that log reliably do it because a weekly ritual checks the logs, not because the field exists.

It is not a timesheet. The data is stored per work item, not per person per day. Reconstructing what one person did last Tuesday means querying across items and adding it up. The built in time tracking report compares original and current estimates for items in a space, which answers whether the work is running over, not what to put on an invoice.

It carries no money. There are no rates, no billable flag, and no separation between time that a client pays for and time that the team absorbs. The two numbers a services business needs, hours delivered and hours invoiced, are not distinguishable in the native fields.

It only covers work that exists as an item. The review that happened in a call, the half day lost to an environment problem, the recruitment conversation: none of that has a ticket, so none of it is in the total. A team whose logged hours account for sixty percent of the working month is not being careless. It is reporting only the portion of its work that was ticketed.

Making the logs worth reading

None of the gaps above is fixed by asking people to be more diligent. What changes behaviour is narrowing what gets logged and giving the numbers somewhere to go.

Start by deciding the unit of logging and writing it down in one sentence. Logging per item per day is the version that survives, because it can be reconstructed from memory at the end of an afternoon. Logging per interruption produces detailed data for two weeks and then nothing. Pick the coarser one.

Then agree on what happens to work with no ticket. The two workable answers are a small set of standing items, one for support, one for interviews, one for internal meetings, or an explicit decision that untracked work stays untracked and the totals are read as ticketed hours only. Both are honest. What breaks trust is a total that looks like a full month and is not.

Fix the estimate conversation next. The comparison that people find useful is not estimate against actual on a single item, where being wrong is normal and says little. It is the pattern across a category of work, where the same kind of task consistently takes twice the estimate. That needs the estimate to be recorded before the work starts, which is a discipline question, not a tooling one.

Finally, schedule the moment the numbers are read. A fifteen minute review at the end of each week, where the logged totals are looked at next to what was actually delivered, does more for data quality than any reminder. Logs that nobody reads decay quickly, because the cost of a sloppy entry is invisible. Time data is only maintained where somebody visibly uses it.

When an app is the answer, and what it actually costs

Jira Cloud supports custom time tracking providers, so an app can replace the native behaviour rather than sit beside it. The Atlassian Marketplace has a long list of these, and the well known ones add timesheet views, approval workflows, billable rates and per person reporting.

The cost surprise is not the sticker price. Marketplace apps on cloud match the user tier of the host product and cannot be licensed below it. An app cannot be bought for the five people who actually fill in timesheets on a site with sixty users. The app is licensed for the site.

Tempo Timesheets, the most widely installed of these apps, illustrates the shape. Its monthly cloud pricing on the Marketplace is a flat 10 US dollars for one to ten users, then 5.99 US dollars per user for eleven to one hundred users, and 4.21 US dollars per user from one hundred and one to two hundred and fifty, as listed on 27 September 2026. A forty person Jira site therefore pays for forty seats regardless of how many people submit a timesheet, which is roughly 240 US dollars a month on top of Jira itself.

That is worth it for an organisation that bills by the hour and needs approvals. It is a poor trade for a team that wanted to know roughly where the month went. Before committing to it, the total is worth comparing against what a single per person price includes elsewhere, since a board tool with tracking already in it removes the second licence entirely.

Deciding what to change first

Check the four global settings before anything else, because incorrect hours per day, days per week and default unit make every historical total unreliable and cost nothing to fix. Then decide honestly which question is being asked. If the answer is invoicing and approvals, a timesheet app priced for the whole site is the right purchase. If the answer is knowing whether work is running over, the estimate and remaining fields already do that once the units are right and one weekly review reads the logs aloud. If the answer is that the board, the discussion and the schedule are in three different tools and nobody logs anything anywhere, the tracking is not the problem, and a single place where the boards and the conversation live together is the cheaper fix. Pinateca keeps kanban, Gantt, calendar and chat on the same boards, free for up to five people and ten boards.

Q1. Does Jira have a built in timer that starts and stops?

The documented way to record time in Jira Cloud is to open a work item, choose Log work, and enter a duration such as 2d 4h 30m. Entering time after the fact is the native flow, and stopwatch style tracking is what most Marketplace time tracking apps add. Jira Cloud supports custom time tracking providers, so an app of that kind can replace the built in behaviour rather than run alongside it.

Q2. Why do logged days convert into the wrong number of hours?

Because a logged day means whatever the Working hours per day setting says, and a logged week means whatever Working days per week says. Both accept decimal values, so a seven and a half hour day can be configured accurately. Until they match reality, every total that includes a d or a w entry is wrong by a fixed multiplier.

Q3. Can time logs be hidden from other members of the team?

Yes. There is a setting that restricts the visibility of user time log entries to a chosen role or group. With it disabled, individual entries are visible by default to anyone who can view the work item. Teams with a mix of employees and contractors on the same boards usually want this restricted before the first month of logs accumulates.

Q4. Why is the Log work action missing for some people?

Logging requires the Work on work items permission in that space, granted through the permission scheme. Editing an existing entry is separate and needs Edit own work logs or Edit all work logs. When someone can see the time tracking fields but cannot record anything, the permission scheme is the first place to look rather than the field configuration.

Q5. Does time from subtasks roll up to the parent item?

It does, within a limit. Children cannot be included in an item's time tracking once that item has more than 100 child work items, and Atlassian recommends staying under that number. Epics carrying several hundred tickets will not produce a correct total, so hierarchies intended for time rollup should be designed with that ceiling in mind.