{{tl-dr}}
Finance asks for last month's hours per person, per client. The Jira admin knows the data exists, because everyone logs time on their issues. It's just spread across 600 tickets in four projects, and there is no button in Jira that adds it up. That's the moment most people type "Jira timesheets" into a search bar, and it's worth being precise about what they'll find: Jira's time logging is real and reasonably good. The gap is the report. This guide covers what native Jira actually gives you, the workarounds people try, the four places teams hit a wall, and what changes when you add a timesheet app.
Does Jira have timesheets?
Jira has native time tracking but no native timesheet. You can log time on any issue, with estimates and time spent, and control who can edit those entries. What you can't get out of the box is a per-person, per-period view of logged hours across projects, which is what most people mean by "timesheet."
Since most articles on this topic are vague about the native side, here is exactly what Jira gives you.
The Time Tracking field and the Log Work dialog. Every issue carries Original Estimate, Remaining Estimate, and Time Spent. Log Work asks for time spent, the date the work started, how to adjust the remaining estimate, and a description. Each entry is a worklog attached to that issue. This part works fine, and it's where all your data lives.
Permissions. Jira's project permission scheme has five controls for logged time: Work On Issues, Edit Own Worklogs, Edit All Worklogs, Delete Own Worklogs, and Delete All Worklogs. Those five are the whole story of who can change a logged hour. There's no concept of "approved," and a worklog stays editable by anyone with the permission for as long as the issue exists.
The Time Tracking Report. Jira Software's company-managed projects include one built-in time report. It takes a fix version and compares original estimates against time spent and remaining estimates for the issues in that version. It's useful for exactly that question ("how far off were our estimates for this release?") and for nothing else. It doesn't group by person, doesn't take a date range, and doesn't span projects. Team-managed projects don't have it at all.
Workload reports and gadgets. The Workload Pie Chart report and gadget show time spent (or estimates) split by assignee for a project or filter. The User Workload report shows remaining estimates per person. Both are useful for a rough "who's carrying what" picture, and neither is a timesheet: no dates, no daily breakdown, no totals for a period.
The Time Tracking Provider setting. On Jira Cloud, Settings → Issues → Time Tracking lets you choose which app handles Log Work. By default it's Jira itself. This is the door Marketplace apps use to replace the dialog while leaving your existing worklogs exactly where they are. Keep it in mind for later.
How do you get a timesheet report in Jira?
Natively, the closest thing to a Jira timesheet report is a JQL search in the Issue Navigator: worklogAuthor = "jane.doe" AND worklogDate >= "2026-08-01" AND worklogDate <= "2026-08-31", with the Time Spent column added and the result exported to CSV. It gives you one person's issues for one period. It does not give you a total, and it has a trap.
Here's the recipe in full:
worklogAuthor = "jane.doe"
AND worklogDate >= "2026-08-01"
AND worklogDate <= "2026-08-31"
Run it in the Issue Navigator, switch to list view, add the Time Spent column, and export. You'll get every issue Jane logged time on in August.
Now the trap. The Time Spent column is the issue's lifetime total, from everyone, since it was created. It is not the time Jane logged in August. If Jane logged two hours on a ticket that already had thirty hours on it from three other people, the column says thirty-two. Most first-time timesheet spreadsheets built from this export are wrong for exactly this reason, and nobody notices until finance compares two months and the numbers don't reconcile.
To get the real per-period figure you have to open each worklog, which means reading the issue's work log tab or pulling worklogs through the REST API. At that point you're writing a script, not running a report.
The other native option is the Time Tracking Report described above, and it's worth being clear about why it isn't a timesheet either: it's organized around a release, not around people or dates. Ask it "how much did the team log last week?" and it has no way to answer.
So the honest native answer is one author per query, issue-level rows, no daily breakdown, no cross-project total without a spreadsheet, no billable flag, and you rebuild it by hand every period. It works for one person checking their own month. It stops working the first time someone asks for the whole team.
Where do teams hit the wall with Jira timesheets?
Teams hit the wall in four places: per-person and cross-project totals, billable versus non-billable time, approval and locking, and time that isn't on a Jira issue. Each one is the moment a different kind of team goes looking for an app.
Per-person and cross-project totals
This is the wall from the previous section, and the usual response is a spreadsheet. Export per person, paste into a tab, sum the columns, send to finance. It works for a month or two. Then someone edits a worklog after the export, the spreadsheet and Jira disagree, and the question becomes which one is right. The answer is Jira, always, which means the spreadsheet was never the record. It was a snapshot that aged the moment it was saved.
Billable versus non-billable
Jira has no concept of billable time. A worklog is a worklog. Teams try prefixes in worklog comments, or separate "internal" projects, or a custom field on the issue (which doesn't help when one issue has both kinds of time). Every workaround depends on people remembering a convention, and conventions are the first thing to go in a busy week.
Approval and locking
With the five worklog permissions, you can decide who is allowed to edit logged time. You can't decide until when. A worklog from last quarter is as editable today as it was the day it was logged, and nothing records that anyone ever reviewed it. For a 15-person team this is fine. For an organization that invoices from those hours, it's a number that can change after the invoice went out. We've written a separate guide on how to design a timesheet approval process, because it's a real process question, not a checkbox.
Time that isn't on a Jira issue
Native Jira can only log time against an issue. Meetings, training, planning days, the two hours helping another team: none of it has a ticket. Teams either create a permanent "Meetings" issue per person (and quietly pollute their backlog and their reports), or they don't log it and then wonder why nobody's timesheet ever reaches 40 hours. Both answers are bad, and the second one makes every utilization number on the team look worse than reality.
How to get real timesheets in Jira with ActivityTimeline
ActivityTimeline is our time tracking and resource planning app for Jira. For timesheets specifically, it does two things: it plugs into Jira's own Log Work dialog so nobody changes how they log, and it turns the worklogs that are already in Jira into per-person, per-period timesheets with the four walls handled. Here's how that maps to each one.
Logging time where people already are
Set ActivityTimeline as the Time Tracking Provider in Jira Cloud, and Log Work on any issue opens the ActivityTimeline dialog instead of Jira's. Same place, same button, a few more fields: a worklog category (billable or not), the option to log across several days in one entry, a favourites list for the issues you log against every week, and a worklog table on the issue itself showing the total and the per-person breakdown. Existing worklogs stay where they are. Nothing migrates, because nothing needs to.
People who prefer a personal view can log from Workspace instead: a Log Work button, a timer, a click on the day's bar chart, or resizing an existing worklog to cover another day. The remaining estimate on the Jira issue adjusts either way.
Two small features matter more than they sound. Managers can log time on behalf of someone who forgot (with a visible warning that they're doing it), which is how you keep timesheets complete without chasing people on Friday afternoon. And a worklog backdate limit stops anyone logging time weeks into the past, with options up to 45 or 75 days back for organizations with longer accounting cycles.
The per-person, per-period view: three timesheet types
Once the worklogs are there, the Track module gives you three ways to read them, and they answer three different questions.
"Is everyone logging?" The Progress timesheet shows required hours against logged hours per person, color-coded for over- and under-logging, so a lead can see in ten seconds who's complete and who isn't.
"Where did the hours go?" The Timeline timesheet shows hours per person per day, week, or month, grouped by project, epic, or any Jira custom field. It takes Jira saved filters, so a "client X" filter becomes a client X timesheet without rebuilding anything.
"Show me every entry." The Detailed timesheet lists each worklog with user, issue, date, hours, comment and approval status, plus an optional Position column so you can see how roles split their time. This is the one finance wants.
“Are we on track?” The Alignment report in Timesheets allows you to compare Planned time vs Logged time over a selected period. This report helps you understand how accurately the work was executed against the plan by showing:
- How much time was planned
- How much time was actually logged
- the difference (Δ Delta, Hours)
- the ratio between them (Plan Match, %)
It is useful for managers, team leads, and project managers who want to track whether work is being logged according to expectations.
All four share the same scopes (Team/People, Project, Epic, Category, Issue, or a Jira filter), an Exclude option for hiding what you don't need, templates and custom grouping, and saved dashboards so the weekly report is a click, not a rebuild. Every view exports to Excel with one button, including values from rich-text custom fields. Historical range used to stop at two years; that limit is gone, and a single report can now cover up to two years at a time from any point in the past.
Billable and non-billable
Worklog categories replace the comment-prefix convention. Billable and Non-Billable exist out of the box; you can rename them, add more, and set a default per project so everything logged in an internal project lands as non-billable automatically. If someone logs natively in Jira rather than through the ActivityTimeline dialog, a "~" at the start of the worklog comment marks it non-billable. Timeline and Detailed timesheets group by category, which is how the billable split shows up in the export. For finer coding (cost center, client, location), worklog attributes add custom fields to each entry. If you're measuring billable utilization from this, our resource utilization guide covers the formula.
Approval and locking
ActivityTimeline adds the missing states. Turn on the approval workflow in Timesheets Config and every worklog gets a status; Admins, Managers, Power Team Leads and Team Leads can approve individually or in bulk; approved worklogs lock; the system records who approved what; and weekly or monthly periods can be closed so nothing changes after the invoice goes out. How to set the roles, cadence and close date so that actually works at scale is its own article: see our timesheet approval guide.
Time that isn't a Jira issue
Booking-type events in ActivityTimeline (training, planning day, internal work) can be treated as worklogs, configurable per event type, so they land on the timesheet without a fake ticket. Google Calendar and Outlook events can be imported and treated as worklogs for past and current periods, so meetings show up as logged time automatically, and admins can pick which event types to import.
One honest trade-off here, and we'd rather you hear it from us than discover it in settings: hard period closure works only with Jira issue worklogs. If you enable closure, the options to treat bookings and calendar events as worklogs switch off. Teams that invoice from closed periods and teams that want meetings on the timesheet automatically have to decide which matters more, because right now you can't have both.
Which Jira timesheet app should you pick?
The Marketplace has dozens, and they fall into three groups: timesheet-only tools that report on worklogs, time-plus-billing suites where Tempo is the established name, and time-plus-resource-planning apps, which is where ActivityTimeline sits.
Honestly, the choice is easier than the listing pages make it look, because it depends on the question behind the timesheet. If the question is "invoice this, at these rates, from this product, today," and you want budgets and rate cards in the same suite, Tempo's set of products is the safer answer, and we'd say so to a customer. If the question behind the timesheet is "who's overloaded, who's free, and did the plan survive the week," then the timesheet and the planning need to share one data model, and that's what ActivityTimeline is built for. And if you're already on Tempo and leaning our way, ActivityTimeline imports Tempo worklogs and attributes, so switching isn't a rebuild.
{{rich-cta-3}}
FractureCode did roughly that: they'd been tracking time inconsistently in Jira, and after switching they got visibility across their global teams and met new labor compliance requirements with the same data they'd always had.
