Time tracking in Jira: logging work, Tempo, and simpler alternatives
Jira already tracks time. Every Jira Cloud site has time tracking switched on, and anyone with the right permission can log hours against a work item and compare them with the original estimate. What Jira does not give you out of the box is a weekly timesheet, an approval step, or totals by person and client that someone can turn into an invoice. That gap is why teams start looking at Tempo and other apps.
This guide walks through what the built in feature does and how to configure it, using the setting names Atlassian's documentation uses as of October 8, 2026. It then covers what changes when a Marketplace app takes over, how those apps are priced, and when a separate timesheet outside Jira is the simpler answer.
What Jira time tracking does on its own
Atlassian's "Configure time tracking" page states that time tracking is enabled by default and that disabling or re-enabling it does not lose existing data. In Jira Cloud it is always on at the site level. Each space decides whether the feature is visible:
- Company-managed spaces show or hide the Time tracking field through field configurations.
- Team-managed spaces add or remove the Time tracking field on each work type.
Once the field is visible, three numbers live on each work item: the original estimate, the time spent and the time remaining. The time tracking bar in the details panel shows how much has been logged so far and how much is left.
What it records well
Native tracking is good at one thing: comparing estimated effort with actual effort per work item. The time tracking report shows original and current estimates for the work items in a space and whether each is ahead of or behind schedule. For an engineering team that estimates in hours and wants to learn how accurate those estimates are, this is often enough.
Where it stops
The built in feature is organized around work items, not around people or weeks. There is no screen where one person sees their whole week as a grid and fills it in. There is no submit and approve flow, so a lead cannot lock a week once it has been reviewed. Time spent on meetings, support calls or admin has nowhere to go unless someone creates a work item for it. And there are no rates, so turning hours into money happens in a spreadsheet afterwards.
Atlassian's documentation also notes a structural limit: if a work item has more than 100 child work items, they cannot be included in time tracking, and it recommends keeping to 100 children per parent.
Setting it up: permissions and global settings
Give people permission to log work
According to Atlassian, users need the Work On Work Items permission in a space to track time. To check it:
- Select Settings, then Work items.
- Select Permission schemes.
- Next to the scheme you want, select Permissions.
- In the Time tracking permissions section, find Work On Work Items and select Edit.
- Choose the users, groups or space roles that need to log work, then select Grant.
Editing and deleting logs are separate permissions: Edit own work logs, Edit all work logs, Delete own work logs and Delete all work logs. Decide early whether leads can correct other people's entries, because that choice shapes how much the data can be trusted later.
Set the working week
The global settings are under Settings, then Work items, then Time Tracking in the sidebar under WORK ITEM FEATURES, then Edit global settings. The fields are:
| Setting | What it controls |
|---|---|
| Working hours per day | How many hours count as one day (decimals allowed) |
| Working days per week | How many days count as one week (decimals allowed) |
| Time display format | Pretty, Days or Hours on the Time Spent field |
| Default unit | Minute, Hour, Day or Week when someone types a bare number |
| Copying of comments to work description | Whether transition comments are copied into the work log |
The default unit matters more than it looks. Atlassian's documentation says that if someone types "2" instead of "2h", the admin's default unit applies. If the default is Day and a developer means two hours, the log is off by a factor of the working day. Set the default to Hour unless the team estimates in days.
To let people enter an original estimate when they create or edit a work item, the Time Tracking field must also be on the create and edit screens for those operations.
Logging time day to day
Estimate first
Before work starts, set the estimate in the field your space uses: Original estimate, Work item count, or a custom method. Software spaces also offer Story points for stories and epics. Time can be written in weeks, days, hours and minutes, such as 3w or 2d 4h 30m.
Log the work
Atlassian describes two ways to log time: open the work item and select More actions, then Log work, or select the Time tracking field directly. Fill in the log fields and save.
Correct mistakes
To change an entry, open the work item, find the Work log in the activity section, select the entry, then Edit or Delete. One detail catches people out: when an entry is edited or deleted, the previous values are still used to calculate the time remaining. If the remaining figure looks wrong afterwards, it has to be updated by hand in the edit work log dialog. On delete, Jira offers to add the deleted time back to the remaining estimate automatically or to let you set a new figure.
Habits that keep the data usable
- Log the same day. Hours reconstructed on Friday from memory are rounded and incomplete.
- Put a short note on each log. "Code review" or "client call" makes the report readable months later.
- Agree on a home for non-project time. A single standing work item for meetings and support avoids losing those hours.
When teams add Tempo or another app
Jira lets a Marketplace app replace the built in provider. In the same Time Tracking settings page, admins pick the app from the Time tracking provider dropdown after installing it. Atlassian notes that with a third party provider, the data may be stored with the app developer, and points to each listing's Data Security and Privacy statement.
What apps like Tempo add
Tempo's Timesheets pricing page lists features such as a timesheet view across a period, team level approvals, holiday and workload schemes, accounts for categorizing billable work, internal issues for non-project time like meetings and training, export to CSV or XLS, and calendar integrations on Cloud. Those are exactly the gaps listed earlier: a weekly view, approvals, non-project time and something closer to billing.
How the price is counted
The detail that changes the budget is how users are counted. Tempo's pricing page states that the Tempo license size must match the Jira license size, and that a user is anyone who can log into Jira. The app is priced on every Jira user, not only the people who log time.
The calculator on that page, checked on October 8, 2026, returned these Cloud figures:
| Jira users on the site | Price shown per month | Average per user |
|---|---|---|
| 5 | $10.00 | $2.00 |
| 10 | $10.00 | $1.00 |
| 11 | $65.89 | $5.99 |
| 15 | $89.85 | $5.99 |
| 25 | $149.75 | $5.99 |
The step from 10 to 11 users is the one to notice. A site that adds one Jira user for any reason, a designer who only comments or a client who only views, moves the timesheet bill from $10.00 to $65.89 a month at those figures. Jira's own Free plan is listed for up to 10 users, so the same boundary appears on both sides.
Choosing between native tracking, an app, or a separate timesheet
| Situation | Usually enough |
|---|---|
| Developers compare estimates with actuals per work item | Native Jira time tracking |
| Leads need weekly approval and non-project time, everyone already lives in Jira | A Marketplace app such as Tempo |
| Hours feed invoices for contractors, many Jira users never log time | A timesheet priced on the people who enter hours |
| The team is small and Jira itself feels heavy | A lighter project tool with timesheets built in |
Stay with Jira and an app when
The work is software development, the people logging time are the same people moving work items, and reports need to tie hours to specific work items, epics or releases. Keeping everything in one place avoids copying data between systems, and the app can read Jira's structure directly.
Before buying, run the free trial with the people who will actually approve timesheets, not only the admin. The question to answer in the trial is whether leads open the approval screen every week without being chased. If they do, the app is earning its cost. If approvals pile up, the problem is the process, and a different tool will not fix it.
Look at a separate timesheet when
The people who log hours are mostly contractors, the hours become invoices, and a large share of Jira users never log anything. Pricing based on everyone who can sign in then charges for people who do not use the feature. A timesheet that counts only the people entering hours, records contract type and rate, and prints a report per person is a closer fit for that job.
This site's own timesheet add-on is one example of that model. Its pricing page lists it at $9 per user per month, or $7 per user per month paid annually, and states that only the people who enter hours are counted, while managers who only view or approve are not. It records time in half hour steps on a weekly sheet, supports hourly, per project and fixed monthly contracts, and has weekly submission and approval with totals by person, project and work type. It does not read Jira work items, so it suits teams whose billing does not need to tie hours to specific Jira tickets.
If the broader question is whether Jira is the right project tool for a small team at all, the comparison pages set common tools side by side on plan limits and features.
Common mistakes that make Jira time data unreliable
- Leaving the default unit on Day. Bare numbers get multiplied into days and nobody notices until the report.
- Counting on remaining estimates after edits. Edited or deleted logs do not recalculate remaining time on their own.
- No place for meetings. If non-project time has no home, utilization looks lower than it is.
- Logging without notes. Totals without context cannot answer a client who asks what the hours were for.
- Switching providers mid-quarter. Changing the time tracking provider moves where data lives. Do it at the start of a reporting period.
What to change first
Open Settings, then Work items, then Time Tracking and confirm the default unit is Hour, then check who holds Work On Work Items. If the hours feed invoices and many Jira users never log time, price a timesheet that counts only the people entering hours, such as the one in Pinateca, before adding an app billed on every Jira user.
Q1. Does Jira have built in time tracking, or is a plugin needed?
Jira Cloud has time tracking built in and enabled by default. Users with the Work On Work Items permission can set an original estimate and log time on each work item, and the time tracking report compares estimates with actuals. A plugin is needed for things like weekly timesheets, approvals and billing reports.
Q2. Why does Jira record days when hours were meant?
If a number is entered without a unit, Jira applies the default unit set by the admin under the global Time Tracking settings. When that default is Day, typing "2" records two days. Typing "2h" avoids it, and an admin can change the default unit to Hour.
Q3. Does Tempo have to be licensed for every Jira user?
According to Tempo's pricing page, the Tempo license size must match the Jira license size, and a user is anyone who can log into Jira. So the license covers every Jira user on the site, not only those who log time. The calculator showed $10.00 a month up to 10 users and $5.99 per user from 11 users when checked on October 8, 2026.
Q4. How is the remaining estimate fixed after editing a work log?
Edited or deleted work logs do not change the previous values used to calculate time remaining. Open the work item, find the entry in the Work log section and update the remaining time manually in the edit work log dialog. When deleting, choose whether Jira adds the deleted time back automatically.
Q5. Can Jira track time for meetings that are not tied to a ticket?
Native Jira tracking only logs time against work items, so meetings need a work item to log against. Many teams create one standing work item per month for meetings and support. Apps such as Tempo offer internal issues for non-project time like meetings and training.