Worktime for Jira

Coming soon to the Atlassian Marketplace

Overview

Worktime is a Forge-native app for Jira that turns worklogs into HR-ready period reports. It reads the time your team already logs in Jira (or in Tempo, Clockwork or eazyBI), compares it against each technician's contracted hours, shifts and holidays, and produces per-period figures for worked, expected, overtime and shortfall hours — plus a running recuperation balance. Periods can be locked with an audit trail and exported as XLSX or CSV, or pulled via a REST API, for handoff to any HR or payroll system. Worktime is a calculator and handoff layer, not an HRIS replacement: it does not push data into your HR system or store sensitive HR documents.

Prerequisites

• A Jira Cloud site — any tier (Free, Standard, Premium or Enterprise).
• Worklogs being recorded in Jira, or an account with a supported third-party source (Tempo, Clockwork or eazyBI).
• Jira administrator access for the initial configuration. Day-to-day technician self-views do not require admin access.

Getting started — your first report in five minutes

1. Install Worktime from the Atlassian Marketplace onto your Jira Cloud site.
2. Open it from Apps → Worktime in the top navigation. Worktime registers as a Jira global page and an admin page.
3. On first launch, open the admin page and confirm the worklog source. The default is native Jira worklogs — no configuration needed.
4. Add at least one contract (the expected weekly or monthly hours for a technician) so Worktime has something to measure worked time against.
5. Open the global page and select the current period. Worktime reads the worklogs for that period and shows worked, expected, overtime and shortfall per technician.

Choosing a worklog source

Worktime can read time from one of four sources. You choose the source on the admin page; only one is active at a time.

If you use native Jira worklogs, Worktime contacts no service other than the Atlassian API. See the Security page for the full egress detail.

Configuring contracts, shifts and holidays

All configuration is point-and-click on the admin page — there is no JSON to hand-edit.

• Contracts — set the expected hours for each technician (weekly or monthly). This is the baseline that worked time is compared against to derive overtime and shortfall.
• Shifts & rotations — define shift patterns and rotation cycles so expected hours match how the team actually works across the period.
• Public holidays — maintain a holiday list per region. Use Import holidays to pull a country's national public holidays for a given year in one click (this calls a public holidays API with only the country code and year), or enter holidays manually.
• Overtime & recuperation rules — define how overtime accrues and how recuperation is drawn down. Worktime applies these rules when computing balances.
• Markup grid for absences — record HR-managed absences (sick, vacation, training) so expected hours adjust correctly. This is how HR-side absences enter Worktime; the app does not manage absences end-to-end.

Understanding recuperation balances

A recuperation balance is the running total of overtime a technician has accrued but not yet taken back as time off. Worktime increases the balance when worked hours exceed expected hours (subject to your overtime rules) and decreases it when recuperation is taken (recorded via the markup grid). Each technician can see their own balance on the global page; admins see balances across the team. Because balances are derived from locked periods, they stop drifting once a period is signed off.

The lock workflow

1. Review a period's figures on the global page.
2. When the numbers are correct, lock the period. Locking freezes the worked, expected, overtime, shortfall and recuperation figures for that period.
3. Every lock is recorded in an audit log (who locked it, when), so signed-off figures are traceable and cannot silently change afterwards.
4. If a correction is genuinely needed, an admin can unlock, adjust and re-lock — each action is captured in the same audit trail.

Verifying a locked period (drift check)

A locked report is an immutable snapshot: it keeps showing the same numbers even if someone later edits the underlying Jira worklogs. To check whether that has happened, run a drift check from the report's actions. Worktime re-reads the source for the period and compares it against the worklogs captured in the snapshot, reporting how many worklogs were added, edited or removed since the lock (and which technicians are affected). A clean result confirms the signed-off period still matches Jira; if drift is found, it's recorded in the audit log so the divergence is traceable. This is what lets a locked period stay trustworthy without freezing your source data.

Exporting to your HR system

Locked (or in-progress) periods can be handed off three ways:

• XLSX / CSV export — download a period report formatted for handoff and drop it into your existing payroll or HR process. The Excel workbook bundles every view as separate sheets.
• Working-time record — a per-technician daily record (first-in, last-out, break and net worked time) for statutory working-time recordkeeping, as a CSV or an Excel sheet. This is recordkeeping support, not legal advice — your compliance team decides whether it meets your local mandate.
• REST API — pull the same period data programmatically for direct integration with a downstream HR system.

REST API reference

Worktime exposes a read API for period data so downstream systems can pull figures without a manual export. Requests are authenticated with an admin-generated API key and are served by Forge's own runtime.

• Authentication — generate an API key on the admin page and pass it on each request. Keys are customer-owned and can be revoked.
• Period figures — retrieve worked, expected, overtime, shortfall and recuperation values per technician for a given period.
• Formats — responses are JSON; the same data backs the XLSX and CSV exports.

Full endpoint paths and payload schemas are published here once the app is live on the Marketplace.

Support

For support enquiries: support@3t-apps.com

Support hours: Monday–Friday, 9:00 AM–5:00 PM CET. Target response time: 1 business day.

Visit Support page → · View full SLA →