Timesheets for Jira Cloud

Last updated 2026-10-31

Timesheets adds a weekly timesheet to Jira Cloud. Hours are stored as standard Jira worklogs; the app adds approvals, locked periods, account tags and an export. It is a paid app on the Atlassian Marketplace, built on Atlassian Forge. This page is for the three people who use it: the person logging time, the approver and the Jira admin.

Before you start

Time tracking must be turned on in Jira (Jira settings, Issues, Time tracking). Without it Jira refuses every worklog.
People need Jira's usual permissions to log time on an issue: Browse projects, Work on issues, and Edit own worklogs and Delete own worklogs to change or remove their hours. The app writes as the person, so Jira's permission scheme decides what each person can do.
The first time someone opens the timesheet, Jira asks them once to allow the app to act on their behalf. Choose Allow access.

Set up (Jira admin)

Open Jira settings, Apps, then Timesheets settings. Only people with Jira's Administer permission can use this page.

Time zone of the books. An IANA name such as Europe/Stockholm. Every day in the app is a day in this zone, whatever zone a person's browser is in.
Weekly hours. The standard week, 40 by default. Distribute fills the week up to this number.
Client accounts. One per line, ID | Name, for example ACME | Acme Corporation. Billable time needs a client account.
Project defaults. One per line, PROJECT | TAG | CLIENT, for example CLI | BILLABLE | ACME or PLAT | CAPEX. A new row on the grid starts with its project's tag.
Teams. One per line: Team name | members | tier 1 approvers | tier 2 approvers, up to four tiers. People are given by Atlassian account id, separated by commas. To find someone's account id, open their Jira profile: the id is the last part of the address (.../jira/people/<account id>).

Rules the settings page checks: a person is a member of one team; an approver is in at most one tier of a team; a member is never the only approver of a tier (their own weeks could never pass it).

Save settings. Changes to a team do not move weeks already submitted: each submitted week keeps the chain it was submitted to.

Log your week

Open Apps, then Timesheet.

The grid shows one week, Monday to Sunday, with a row per issue and tag and a column per day. It is read from your own Jira worklogs, so time you logged in Jira's own screens is there too.
Type hours as 7.5, 7,5, 7:30 or 7h 30m. An empty cell or 0 removes the hours for that day.
Add issue puts a row in by key, such as ABC-123, with its project's default tag. You can only add issues you can see in Jira.
Tag each row: Billable (with a client account), Non-billable, CAPEX or OPEX.
Distribute spreads the weekly hours over the rows you ticked, on the open weekdays, in quarter hours. Check the result, then save.
Save writes the changes to Jira as worklogs authored by you. One save handles up to 60 changes. If Jira refuses some of them, the page lists which ones and reloads the week from Jira.

Read-only cells: a day in a locked period, and a day where one row holds two or more worklogs (the app cannot tell which one to change; change it in Jira's Work log tab).

Submit

Submit sends the week to tier 1 of your team. Save first. While a week is submitted it is read only. You can Withdraw it until the first approver has acted. If it is rejected, the feedback is shown at the top of the week; correct it and submit again.

A week with hours on more than 200 issues cannot be submitted: the app reads at most 200 issues for one week and will not submit a week short.

Approve (approvers)

The Approvals tab on the timesheet page lists the weeks waiting at your tier.

Each week shows its lines, tags and totals. An issue's summary is shown only if you can see that issue in Jira.
Lines changed in Jira after the week was submitted are marked, so you approve what is really there.
Approve passes the week to the next tier, or approves it if yours is the last. Reject needs feedback, which the owner sees.
You never act on your own week, and one person passes one tier of a week.

Reopen an approved week

Below the waiting weeks are the approved weeks of the last eight weeks that you may reopen: as an approver of the last tier of that week's chain, or as a Jira admin. Give a reason and choose Reopen. The week goes back to its owner as open, with your reason as feedback, leaves the export, and must be submitted through every tier again. Who, when and the reason are kept on the week and in the audit log. A week with any day in a locked period cannot be reopened, and nobody reopens their own week.

Lock a period (Jira admin)

On the settings page, choose a past date range, tick the box to confirm, and Lock. A lock is permanent.

From that moment the app refuses changes to hours on those days. In the background it records every worklog it can read in the period as the value that was closed; the status of that work is shown next to the period.

What a lock does not do: Jira itself does not know about it. Anyone with the project permissions can still change a worklog on a locked day in Jira's own screens or through Jira's REST API. The app detects such changes (from Jira's worklog events within minutes, and from a daily check of Jira's change list) and records each one in the audit log. For a hard stop, remove the edit and delete worklog permissions from the project's permission scheme once a period is closed.

Audit log (Jira admin)

The settings page lists, newest first:

worklogs created, changed, moved into or deleted from a locked period;
worklogs changed or deleted after their week was submitted, and hours added to a week already submitted or approved;
approved weeks that were reopened.

Each entry has who made the change, when, and the value before and after where the app had recorded it. The app cannot see worklogs whose visibility is restricted to a group or role it is not in.

Export (Jira admin)

Choose a date range (up to 400 days), CSV or JSON, and whether to include submitted weeks as well as approved ones. The file is offered as a download and also shown as text to copy.

Columns: date, weekStart, accountId, person, issueKey, issueSummary, hours, seconds, category, clientAccount, clientAccountName, team, sheetStatus, approvedBy, approvedAt, periodLocked, auditFlags, worklogId.

The export uses the hours as approved. A correction made in Jira after approval is flagged on the line and reaches the export only when the week is reopened and approved again. Text that a spreadsheet could read as a formula is exported as text.

Your data

Runs on Atlassian: the app runs on Atlassian's infrastructure. Nothing leaves Atlassian: the app calls no outside server and has no analytics, and we run no servers that receive your Jira data.
Hours are Jira worklogs and stay in Jira if the app is removed.
Everything else (tags, weeks and their history, settings, locked periods, the audit log, display names) is kept in the app's storage on Atlassian's platform.
When a person's Atlassian account is closed, the app removes their name and replaces their account id with an anonymous one in its records, within about a week.
Uninstalling the app deletes its storage (Atlassian's platform does this); the worklogs remain in Jira.

Check recorded time before using it for payroll or invoicing.

When the license is not active

When the site's subscription to Timesheets lapses, everything stays readable: your weeks, the approvals tab, the settings page, the audit log and the export. Logging hours, submitting, withdrawing, approving, rejecting, reopening, saving settings and locking periods are off until a site admin renews the license, and each page says so. Hours already logged stay in Jira, and the app keeps recording changes made in Jira to locked periods and submitted weeks.

Limits

Jira Cloud only.
One time zone for the books. A locked period keeps the zone it was locked in.
People are entered by account id in the settings; there is no user picker.

Legal

Support

Email alexander@inventerprises.se. The Support page says what to include in a report.