Time And History for Jira: Documentation

Overview

Time And History is an app for Jira Cloud that measures how long your issues spend in every stage of your workflow. It reads the Jira issue history — every field change Jira records on an issue — and converts it into working time using your own work calendars, so weekends, evenings and holidays never inflate the numbers. This guide covers version 2.3 of the app, which runs on Jira Cloud.

The app includes five reports:

• Time in Status — how long each issue stayed in every workflow status, as a table with Avg / Median / Min / Max per status or as interactive charts;
• Time in Changes — the Jira issue history, field by field: who changed what, when, and how long each previous value lasted;
• Assignee Time — how long each issue spent with every assignee;
• Time to Resolution — how long issues take from creation to each resolution, in business hours;
• Transition Count — how many times each status pair occurred on an issue, so rework and reopens become a number (see Transition Count).

Two features cut across the reports: the Between Statuses columns, which measure the working time between any two statuses on Time in Status, and scheduled reports, which mail any report to your team daily, weekly or monthly.

Inside Jira the app is available from three places:

• the Time And History item in the Jira top navigation bar opens the five reports and the Scheduled Reports page;
• Jira dashboards — eight dashboard gadgets (a chart and a table for four of the five reports) in the Add a gadget picker;
• Jira Settings → Apps contains the Time And History section with the Access Settings and Calendars admin pages.

Getting started

1. Install the app. Get Time And History on the Atlassian Marketplace — free for up to 10 users on Jira Cloud. Right after installation the Get Started page walks you through the first steps.
2. Explore the reports. Open Time And History from the Jira top navigation bar, pick a project and a date range, and see where time goes.
3. Set up work calendars. Define business days, work hours and holidays so every duration counts only real working time (see Work calendars).
4. Grant access to your teams. Choose which Jira groups can view reports and manage calendar or permission settings (see Access Settings).
5. Put the numbers on a dashboard. Add a Time in Status, Assignee Time, Time to Resolution or Time in Changes gadget to any Jira dashboard so the team sees the figures without opening a report (see Jira dashboard gadgets).
6. Send the report by email. Set the filters on a report page, then open Scheduled Reports and create a schedule — daily, weekly or monthly, to up to ten recipients you type yourself (see Scheduled reports by email).

Reports & filters

All five reports filter by project, epic, sprint, reporter, assignee and date range, shown above the report table. The other controls differ in exactly two places: Time in Changes replaces the Columns selector with its own History by Fields control, and Transition Count has no work calendar and no time format, because it counts events rather than working time. Every other report has all three. The app remembers your selection: the next time you open it, your report, filters, calendar, time format and columns are restored exactly as you left them.

Filters

• Project — the project to report on (single select);
• Epic, Sprint, Reporter, Assignee — multi-select filters with a Clear all action; an empty filter means “Any”;
• the calendar selector — the work calendar every duration in the report is computed against; it is your own setting, shared by every report that measures time and by your gadgets (see Work calendars).

Changing the project reloads its epics, sprints and users and resets the dependent filters.

Date range

The Period filter limits the report to a date range. Pick a preset — Any Days, Yesterday, Last 7 Days, Last 30 Days, This Month, Last Month — or choose a custom range with a start and an end date on the calendar. The range is applied to one of three issue date fields:

• Created — shows issues created in the selected period;
• Updated — shows issues updated in the selected period;
• Resolved — shows only resolved issues from the period.

Time formats

Durations in the four reports that measure time can be displayed in four formats; the choice is saved per user. The format changes only the unit — the value behind it is always the same working time, counted against your work calendar. The table below shows one and the same duration in all four formats.

Switching between the formats never re-counts anything: the app calculates the working seconds once, against your calendar, and each format simply divides that number by hours or by 24 hours. Weekends, evenings and holidays stay excluded in DHM and Decimal Days exactly as they are in HM.

Columns

In Time in Status, Assignee Time, Time to Resolution and Transition Count, the Columns selector controls which Jira fields appear in the report table. Search across all fields (system and custom), switch between Active and Inactive tabs, toggle fields on or off and press Save — the selection is saved per user. The default columns are Type, Key, Priority, Reporter, Assignee and Status. Time in Changes uses a fixed column set instead.

Editing issues inline

Hover over a Type, Priority, Assignee or Reporter cell and click the pencil to open the Edit issue dialog. You can change the issue type, priority, assignee (including Unassigned) and reporter without leaving the report — after saving, the report reloads automatically.

Pagination

Reports are paginated at 15 issues per page. The footer shows the current range (for example, 1 - 15 Of 320) with previous/next navigation, a refresh button and a Send Feedback action.

Time in Status

The flagship report answers the question “where does our time actually go?”. For every issue it shows the working time spent in each workflow status, plus a Total Time From Create Issue column.

Table mode

• one column per workflow status found in the filtered issues — statuses appear automatically, no configuration needed;
• your selected Jira fields as leading columns (issue keys link to Jira, user chips show avatars, statuses and priorities are color-coded);
• empty cells display “-” when an issue never visited a status.

How the Avg, Median, Min and Max footer is scoped

The average time in status for the issues on the current page appears in the table footer, next to the Median, Min and Max working time for every status column, for the total and for every Between Statuses pair column you added. The footer states which page the statistics cover, and issues that never entered a status are not counted for that status. They use the same work calendar and time format as the rows, so the summary and the cells beneath it are always on the same clock. For why the mean and the median disagree, and which issues each of the four numbers covers, read what the Jira average time in status hides on the SolaceIn blog.

Between Statuses columns

The Between statuses pill, to the left of Export, adds a column for the working time between any two statuses you pick — for example In Progress → Done. It belongs to Time in Status and appears on this report only: up to ten pairs, saved for you, shown in the table and carried into every export. See Between Statuses: time between two statuses.

Chart mode

The view toggle in the controls row switches the report to a donut, bar or area chart, with KPI tiles above it covering the whole selection. Chart mode and the tiles work the same way on all five reports, so they have their own section — see Charts & KPI tiles.

Both modes export to XLSX and CSV, and chart mode adds a PNG of the chart on screen — see Export reports to Excel (XLSX), CSV or PNG. The same report is available as a dashboard gadget, and it can arrive by email on a schedule — see Scheduled reports by email.

Related reading: how Time in Status turns Jira transitions into a report on the SolaceIn blog, or Time in Status for Jira Cloud on the product page.

Time in Changes: Jira issue history report

Time in Changes turns the Jira issue history into a report — who changed what, when, and how long each value lasted. The main table lists issues with a Total Time From Created column; every row expands into the issue history behind it.

Issue history drill-down

Click a row (or its chevron) to expand the issue’s history:

• Date — when the change happened;
• Changed By — who made the change;
• Field Key — which field changed (Status, Assignee, Priority…);
• Old Value / New Value — the transition itself;
• Time In Old Value — the working time the previous value lasted, calculated with your work calendar.

The last row of each history shows the current value and the time elapsed since the most recent change.

History by Fields

The History by Fields selector chooses which fields appear in the drill-down. Search the field list, toggle the fields you care about and press Save — the selection is remembered per user. The report covers the standard Jira fields — status, assignee, priority, reporter, issue type, summary, description, labels, due date and resolution. What it does not read are the fields Jira records under a display name rather than a field key: custom fields, and system fields such as attachment, fix versions and components. Toggle one on and the drill-down stays empty.

On a dashboard, the Time in Changes gadget counts the number of changes per selected field instead of listing them. The report page has a chart mode of its own — changes per field as a bar, donut or area chart, with KPI tiles above it (see Charts & KPI tiles).

Related reading: Jira status change history: who changed what, and when on the SolaceIn blog, or Time in Changes on the product page.

Assignee Time

Assignee Time shows how long every issue spent with each assignee — ideal for understanding who carries the load and balancing work across the team.

• one column per assignee, with avatars linked to their Jira profiles;
• an Unassigned column accumulates the time issues spent without an assignee;
• the Total Time From Create Issue column sums each issue’s full working age.

For a team-level view, the Assignee Time (Table) dashboard gadget summarises the same data per person: KPI tiles for the total time, issues tracked, number of assignees and average time per issue, plus a table in which each assignee expands into per-status rows.

The report page itself also has a chart mode — hours per assignee as a donut, bar or area chart, with KPI tiles for the whole selection above it (see Charts & KPI tiles).

Related reading: workload per assignee in Jira on the SolaceIn blog.

Time to Resolution

Time to Resolution measures how long issues take from creation to being resolved, in business hours from your work calendar — the honest version of your delivery time.

• each resolution gets its own column, named after the resolution value with an ordinal for repeats; an issue resolved as Done, reopened and resolved again is kept apart as Done 1st and Done 2nd, and one closed as Won’t Do reads Won’t Do 1st, so you can see how often issues come back and on what verdict;
• the Total Time To Resolution column sums the working time across an issue’s resolution passes; the stretch an issue spends already resolved, before it is reopened, is not counted;
• unresolved issues display “-” with the hint “The issue has not been resolved yet”.

Every column here exports to XLSX and CSV over each issue the filter matched rather than the page on screen, and the same filter can arrive by scheduled email daily, weekly or monthly.

Related reading: Time to Resolution and the SLA gap on the SolaceIn blog.

Transition Count: how many times statuses change

Transition Count is the fifth report, and the only one that counts events instead of measuring time. For every issue it shows how many times each status pair occurred — Ready for Test → In Progress: 3 — so rework and reopens stop being a feeling and become a number you can sort, chart and export.

What the table shows

• one row per issue, with your selected Jira fields as the leading columns;
• one column per status pair that actually occurred in the filtered issues — the pairs appear on their own, there is nothing to configure;
• a Total column with every transition counted on that issue;
• a TOTAL row under the table, summing each pair column.

Filters

Transition Count filters by project, epic, sprint, reporter, assignee and date range exactly like the other four reports, and it has the same Columns selector. What it does not have is a work calendar or a time format: the values are whole numbers of transitions, so no working time is involved and no calendar can change them (see Reports & filters).

Charts, tiles and export

Chart mode draws the counts as a bar chart — the default on this report — or as a donut or an area chart, and the KPI tiles read Total transitions, Issues tracked, Pairs and Avg transitions per issue (see Charts & KPI tiles). The report exports to XLSX and CSV, and chart mode adds a PNG of the chart on screen (see Export reports to Excel (XLSX), CSV or PNG).

Related reading: which reopens a Jira transition count actually covers on the SolaceIn blog, or Transition Count on the product page.

Between Statuses: time between two statuses

Between Statuses answers “how long from In Progress to Done?”. Pick any two statuses and the working time between them becomes a column in the Time in Status table — one column per pair, counted against your work calendar like every other duration in the app.

Adding a pair

1. Load the Time in Status report for the project and period you care about. The status lists come from the issues on the page, so the report has to be loaded first.
2. Open Between statuses — the pill to the left of the Export button; its badge shows how many pairs you already have.
3. Pick a From, a To and a mode, use Add pair for the next one, then press Apply. Up to ten pairs.

The pill and the columns belong to Time in Status only; the other four reports have neither.

First exit and last exit

The mode decides what happens when an issue loops back:

• First exit (the default) — from the first entry into the first status to the first entry into the second, so later loops are ignored;
• Last exit — from the first entry into the first status to the last entry into the second, so every loop counts.

An issue that went In Progress → Done → In Progress → Done therefore has two honest answers: first exit reports how long the first pass took, last exit reports how long the issue took including the rework. Add the same two statuses twice, once in each mode, and the table shows both numbers side by side. For a worked example of both modes on one reopened issue, and how to read the footer under the columns, read the Jira time between two statuses walkthrough on the SolaceIn blog.

What you get

• one tinted column per pair, headed with the pair — In Progress → Done — and the mode on the line beneath (first exit or last exit); an export joins the two into one header cell, In Progress → Done (first exit);
• that column’s own Avg, Median, Min and Max in the table footer, for the issues on the current page;
• the same columns in every export — XLSX and CSV alike — and in a Time in Status schedule;
• a list saved for you on this Jira site, so the columns come back next session. It is personal: it changes nothing for anyone else.

Related reading: first exit, last exit and a reopened issue on the SolaceIn blog, or the time between two statuses on the product page.

Charts & KPI tiles

Every report page has two modes and one strip of numbers above them. The view toggle in the controls row switches between the table and the chart; the four KPI tiles sit above both, and they always say which issues they cover.

Chart mode

Chart mode is available on all five reports. Chart data is aggregated over all issues matching the filter, not just the current page — a progress bar shows the preparation status, the preparation can be cancelled at any time, and a running chart job survives a filter change instead of starting over.

• Donut chart — the share of the total per series, with a legend showing the values. Click a legend item to hide or show a series; the centre displays the total issue count.
• Bar chart — stacked values per period, with per-series tooltips.
• Area chart — a stacked timeline; the Points view settings show dots on every period and keep numeric labels next to them.

Donut is the default on Time in Status, Assignee Time and Time to Resolution; bar is the default on Time in Changes and Transition Count. For bar and area charts, the Metrics dropdown sets the grouping period: Auto, Day, Week, Month, Quarter or Year, where Auto follows your date range. A donut has no periods, so the control is hidden while a donut is on screen.

Chart mode is also where the PNG export lives: while a chart is open, the Export menu offers Chart Image (.PNG) on any of the five reports (see Export reports to Excel (XLSX), CSV or PNG).

KPI tiles, and which issues they cover

Four tiles sit above every report: a total, Issues tracked, the number of series the report groups by, and an average per issue. The caption above them is the scope contract, and it is worth reading before quoting a number anywhere:

• This page — above a table. The tiles are calculated across the issues on that page only, exactly like the table footer.
• Whole selection — in chart mode. The tiles cover every issue the current filters match, not only the page.

Issues tracked is the second tile on every report. The third tile counts series — statuses, assignees, resolutions, selected fields or status pairs — and not issues. Above a table it counts the series present on that page; in chart mode it counts them across the whole selection, so the two can differ. Time in Changes is the exception: its Fields tile counts the fields you selected, so it is the same number in both modes. While a report is still loading, a tile shows a dash rather than a zero.

Related reading: what the Jira average time in status hides on the SolaceIn blog, which reads the same report at both scopes.

Scheduled reports by email

A schedule sends a report to your team by email — daily, weekly or monthly, at the time and in the time zone you choose — without anyone opening the app. The attachment is the same XLSX the report’s own export builds, and every run is listed in Export History.

Create a schedule

1. Set the filters on a report page first. The schedule takes a snapshot of them. Until a project is selected, creating one is blocked with “Select a project on a report page first”.
2. Open Scheduled Reports in the app sidebar and press New schedule.
3. Fill in the editor — the fields are below — and press Create.

The editor holds, in order:

• Schedule name — 1 to 80 characters;
• Report type — any of the five reports;
• Filters — a read-only snapshot of what is set on the report page. They are fixed when the schedule is created; to report on something else, set the filters there and create another schedule;
• Frequency — Daily, Weekly or Monthly;
• Start date, Start time and Time zone — the editor spells the result out for you, for example Runs every Monday at 09:00;
• Recipients — between one and ten addresses that you type. Nobody is added implicitly, not even you, so add your own address if you want a copy.

The Scheduled Reports list

Each row shows Name, Report, Frequency, Recipients, Last Run and an Active toggle, with a row menu holding Edit, Run now and Delete. Run now marks the schedule due, and the row reads Queued until that run starts.

Last Run is one of Success, Failed, Skipped, Running or Queued — or a dash, when the schedule has not run yet.

What arrives

• the report as an XLSX attachment, as long as the file is 7 MiB or smaller. A larger file is not attached and the mail says it can be downloaded from Export History instead;
• a Time in Status schedule carries your Between Statuses columns;
• every run is listed in Export history as an ordinary export row, and those rows stay there even after the schedule is deleted.

Whose Jira the recipients see

When a schedule stops

• after three consecutive failed runs a schedule is deactivated and the row says so; switch Active back on once the cause is fixed;
• if Jira answers 401 or 403 for the owner — the owner’s own access is gone — the schedule is deactivated immediately, because retrying cannot help;
• Jira rate limiting never deactivates a schedule and does not count towards those three failures: the run reports that Jira is throttling, and the next run retries;
• Skipped means mail delivery is not configured on the deployment.

Who can create one

The Scheduled Reports page is gated by the same Report grant as the report pages: whoever may open the reports may schedule one (see Access Settings).

Related reading: the Jira Time in Status export to Excel on the SolaceIn blog, or scheduled email reports on the product page.

Jira dashboard gadgets

Since version 2.2.0 four of the five reports are also available as Jira dashboard gadgets — each as a chart and as a table. The gadgets use the same calculation and permissions as the report pages, and they inherit your selected work calendar rather than carrying one of their own, so the number on the dashboard is the number in the report. Eight items appear in Jira’s Add a gadget picker, each with a preview: Time in Status, Assignee Time, Time to Resolution and Time in Changes, and a (Table) variant of each. There is no gadget for Transition Count and none for Between Statuses; both live on the report pages.

Add a Time in Status gadget to a Jira dashboard

1. Open the dashboard in Jira and click Edit (you need edit rights on the dashboard).
2. Click Add gadget and search for Time And History. The picker lists the eight gadgets with a preview of each.
3. Pick a chart or a table. Time in Status adds a chart; Time in Status (Table) adds KPI tiles and a table. The same pair exists for Assignee Time, Time to Resolution and Time in Changes.
4. Configure and save. Choose at least a project in the gadget’s configuration form (below) and press Save, then leave the dashboard’s edit mode.

Configure the gadget

Open the gadget menu and choose Configure (the gear). The form holds:

• Project — the project to report on;
• Epic, Sprint, Assignee — optional narrowing filters;
• Period — the same presets as the report pages, or a custom range picked on a calendar with a start and an end date;
• Time format — HM, DHM, Decimal Days or Decimal Hours;
• View — Chart or Table;
• Visualization — Donut, Bar or Area (chart view).

The configuration is saved per gadget instance and applies to everyone who opens the dashboard. Only people who can edit the dashboard can save it; other viewers can still change the filters for themselves (see below).

Filter chips and chart switch

Every gadget shows its current Project, Sprint, Period and Assignee on the card. Changing them re-cuts the gadget for you only — the change lives in your browser session and is not saved to the dashboard, so a reload brings the saved configuration back. Chart gadgets also have an inline donut / bar / area switch that works the same way: it is per session, and the Visualization saved in the gear is what everyone else sees.

Table gadgets and per-status expansion

A (Table) gadget opens with four KPI tiles: the total (Total time in statuses, Total time to resolution or Total changes), Issues tracked, the number of statuses, assignees, resolutions or fields, and the average per issue (Avg time per issue, or Avg changes per issue for Time in Changes).

Below the tiles sits an aggregate table with one row per status, assignee, resolution or field and a Total row. In the Assignee Time (Table) gadget each person expands into per-status rows, so you can see where every assignee’s time went.

A gadget’s tiles are computed over every issue matching that gadget’s own filter — a different scope from the tiles on a report page, which say This page above a table and Whole selection in chart mode (see Charts & KPI tiles).

Open full report

The Open full report link at the bottom of every gadget opens the corresponding report page with the gadget’s filters already applied — the per-issue table and the export are one click away. Every report page adds chart mode and its own KPI tiles; from a Time in Status gadget you also land on the footer with Avg, Median, Min and Max per status for the issues on the current page of the table, which is a Time in Status feature the other report pages do not share.

The eight gadgets

Related reading: the Time in Status dashboard gadget for Jira, step by step on the SolaceIn blog, or the gadgets on the product page.

Work calendars: exclude weekends and holidays

Work calendars define what counts as working time. Every duration in every report and gadget is computed against the active calendar: non-business days are excluded, only the configured work hours count, and holidays that fall on business days are subtracted.

Each calendar consists of:

• Name — up to 25 characters;
• Time Zone — the IANA time zone the calendar operates in;
• Business days — seven weekday checkboxes, plus the Use the same work hours on all business days toggle;
• Work Hours — one shared range (for example 09:00 – 17:00), or an individual range per weekday when the shared toggle is off;
• Holidays — picked on a mini calendar with a description; a holiday can be set to repeat every year (shown with a Yearly label) and can be removed at any time.

A Default Calendar (Monday–Friday, 09:00–17:00, GMT) is created automatically. Create a calendar per team, office or support rota — support and engineering can each measure time against their own schedule. A calendar you no longer need can be deleted from the Calendars page.

The active calendar is a personal setting. Every user picks theirs in the report controls; the choice is stored on the server against your Jira account, so it survives sessions, browsers and devices, and it applies at once to every report that measures time — Time in Status, Assignee Time, Time to Resolution and Time in Changes — and to every dashboard gadget you look at. (Transition Count counts transitions rather than hours, so it is the one report a calendar cannot change.) It is never per report and never per gadget, and switching it never changes what anyone else sees. Until you pick one, you get the default calendar. One consequence worth knowing on a shared dashboard: the same gadget is computed with each viewer’s own calendar, so two people can read different durations from one card.

Related reading: business hours in Jira reports on the SolaceIn blog, or work calendars on the product page.

Export reports to Excel (XLSX), CSV or PNG

All five reports — Time in Status, Assignee Time, Time to Resolution, Time in Changes and Transition Count — export to XLSX and CSV. PNG is a picture of a chart, so it is offered on any report while its chart mode is open. Exports run in the background and always cover all issues matching the current filter, not just the visible page.

1. Set up the report — project, filters and calendar — exactly as you want it in the file. The time format and the column selection apply to the screen only: the file always writes durations as 1h 43m and always carries the same four issue columns.
2. Open the Export menu (the export button in the controls row) and pick MS Excel Report (.XLSX) or Plain Text Report (.CSV); in chart mode, Chart Image (.PNG) is offered as well.
3. Keep working. The export is queued and built in the background; you can change filters or leave the page.
4. Download from Export history. When the status turns to Success, download the file from the Export history panel.

Export history keeps your 20 most recent exports with live progress and status (In Queue, In Progress, Success, Failed). Finished files can be downloaded or deleted at any time; exports are private to the user who created them.

Scheduled runs land in the same list, in the schedule owner’s history, so a daily schedule fills those twenty slots faster than hand-started exports alone. A scheduled file is always an XLSX, and its name carries the word Scheduled; the list itself does not mark it in any other way.

Access Settings

The Access Settings page controls which Jira groups can open each part of the app. Access is granted per group across three areas:

• Report — the report pages, the dashboard gadgets and the Scheduled Reports page: whoever may open the reports may schedule one;
• Calendars Settings — creating, editing and deleting work calendars;
• Permissions Settings — the Access Settings page itself.

Grant access with the Add … buttons, revoke it with the trash icon, then press Save. Reset Changes restores the last saved state. A granted cell shows a green Done chip.

• Jira admin groups (jira-administrators, administrators, site-admins, system-administrators, atlassian-addons-admin, org-admins) always keep full access and cannot be revoked;
• groups that were granted access but no longer exist in Jira are marked Unavailable — their grants can still be revoked;
• users without access to a page see a permission error and are asked to contact their Jira administrator.

Appearance & dark mode

• Follows the Jira theme. Reports, gadgets and settings pages switch between light and dark automatically with the theme you set in Jira (your profile → Theme: light, dark or match system). There is nothing to configure in the app — the in-app theme switcher was retired in 2.2.0, and every report, chart, table and dialog is tuned for both themes;
• Collapsible sidebar — pin the navigation open or unpin it to a compact icon bar that expands on hover; the choice is remembered.

Data & security

• Reports and gadgets are computed on the fly from the Jira REST API — issue data is read transiently, never copied: the app keeps no copy of your Jira issues beyond the export files you explicitly create;
• every Jira read runs as the current user, so existing Jira project permissions always apply — on dashboards as well as on report pages (the one exception is a scheduled run, below);
• the app stores only your preferences (filters, columns, calendar, format and Between Statuses choices), work calendars, access grants, schedule definitions with the recipient addresses their owner typed, export files you created and feedback ratings; gadget configuration is saved in the Jira dashboard item itself;
• every request between the app’s pages and its service is authenticated per request (hardened in 2.2.0);
• the app writes to Jira only when you act: saving the Edit issue dialog changes an issue; saving a gadget’s configuration stores it as a property of that dashboard item. Reports and gadgets never modify issues on their own;
• the 20 most recent export files are listed in Export history, private to their creator and deletable there; older files are removed on request. The files a schedule produced are listed the same way, in the owner’s history, and they stay after the schedule itself is deleted;
• a scheduled report leaves the tenant by email: the XLSX is sent as an attachment to the addresses the schedule owner typed, through the app’s mail provider on AWS;
• processor terms for your legal team: the Data Processing Addendum (GDPR Art. 28) and the Privacy Policy.

Whose Jira permissions apply

Since 2.3.0 every request the app makes to Jira is made as the person using it, on report pages and on dashboards alike. Two people running the same report on the same filters can therefore see different rows, and neither sees an issue their own Jira account cannot open. The app cannot widen anyone’s visibility, and access grants only decide who may open the pages at all (see Access Settings).

The exception is a scheduled report: the run collects as the schedule owner, so its recipients read the owner’s view of Jira rather than their own. Choose the recipients accordingly.

What’s new

2.3.0 — 6 September 2026

New

• Scheduled reports. Any report by email, daily, weekly or monthly at a set time and time zone, to up to 10 recipients, with the XLSX attached and every run listed in Export History — see Scheduled reports by email.
• Between Statuses. Working time between any two statuses on Time in Status, up to 10 pairs, first exit or last exit, saved per user, in the table and in exports — see Between Statuses.
• Transition Count. A fifth report counting every status-to-status transition per issue, with totals and XLSX/CSV export — see Transition Count.
• Chart mode on all five reports — donut, bar and area, with bar and area grouped by day, week, month, quarter or year, or by Auto.
• KPI tiles above every report table (This page) and in chart mode (Whole selection) — see Charts & KPI tiles.

Improved

• Every Jira read runs as the viewing user, so a report shows only the issues that person can see — see Whose Jira permissions apply.

Fixed

• Holidays match the calendar’s own day, not UTC.
• Chart periods follow the calendar’s time zone, the same for every viewer.
• Changelogs longer than 100 entries are read completely in exports and scheduled reports.
• The session token is renewed after 15 minutes, so an open page keeps working without a reload.

Upgrade

• No action needed. Existing gadgets, calendars and access grants keep working; Transition Count and Scheduled Reports appear in the app sidebar.

2.2.0 — 3 September 2026

New

• Eight dashboard gadgets. Time in Status, Assignee Time, Time to Resolution and Time in Changes, each as a chart gadget and a (Table) gadget. Filters on the card, an inline donut / bar / area switch, KPI tiles and aggregate tables, per-status expansion in Assignee Time and an Open full report link — see Jira dashboard gadgets.
• Avg, Median, Min and Max per status in the footer of the Time in Status table — see Time in Status.
• Gadget previews in Jira’s Add a gadget picker, so you can tell the chart and table variants apart before adding one.

Improved

• Dark mode follows the Jira theme automatically; the in-app switcher is gone — see Appearance & dark mode.
• Your time format and column selection are saved and restored per user.
• A running chart job survives filter changes instead of starting from scratch.

Fixed

• The working-time calculation undercounted intervals spanning several days; totals in all reports are now exact to the calendar.
• Backend errors are shown as errors instead of empty results.
• Hardened API request authentication.

Upgrade

• No action needed. Gadgets added before 2.2.0 keep their configuration and keep working.

2.1.0 — September 2026

• Export to XLSX and CSV for all four reports, plus PNG chart images from Time in Status, with an Export history to download files later — see Export reports to Excel (XLSX), CSV or PNG.
• Work calendars can be deleted.
• Per-issue aggregate and table fixes in the reports.
• Contrast fixes in dark mode.

FAQ

My report is empty. What should I check?

Make sure a project is selected and the date range is not too narrow (try Any Days). Remember that you only see issues your Jira account can access.

Why is a duration smaller than the wall-clock time?

Durations count only working time from your active calendar. Time outside work hours, on non-business days and on holidays is excluded. Changing the time format does not change that number: HM, Decimal Hours, DHM and Decimal Days show the same calendar-aware working time in a different unit. The one thing to watch is that in DHM and Decimal Days a "day" is a 24-hour block of accumulated working time, not one business day. See Time formats.

How do I set up a work calendar that skips weekends?

Open Jira Settings → Apps → Time And History → Calendars (or the calendar selector on any report), create a calendar, and tick only the weekdays your team works. Set the work hours for those days, pick the time zone, add your holidays with "repeat every year" for fixed dates, and press Save. Select that calendar in the report controls: every duration is then counted only inside those hours, so weekends and holidays never inflate a number. See Work calendars.

Where is the average per status shown, and over which issues?

In the footer of the Time in Status table, which carries an Avg, Median, Min and Max row for every status column, for the total and for every Between Statuses pair column you added. Those statistics cover the issues on the current page of the table — the footer states which page — and an issue that never entered a status is not counted for that status. The KPI tiles above the table are captioned "This page" and cover the same rows; in chart mode they are captioned "Whole selection" and cover every issue the filters match. The table gadgets add an "Avg time per issue" tile computed over every issue matching the gadget filter. See Time in Status.

How do I measure the time between two statuses?

Open the Between statuses pill on the Time in Status report and add a pair: From, To and a mode. First exit measures from the first entry into the first status to the first entry into the second, so later loops are ignored; last exit measures to the last entry into the second status, so every loop counts. Each pair becomes a column of working time per issue, with its own Avg, Median, Min and Max in the footer, and it travels into XLSX and CSV exports and into a Time in Status schedule. Up to 10 pairs, saved for you on this site. See Between Statuses: time between two statuses.

How many times did an issue change status?

That is the Transition Count report: one row per issue, one column per status pair that actually occurred, and the number of times that transition happened — for example Ready for Test → In Progress: 3. A Total column sums each issue and a TOTAL row sums the issues on the page shown. It counts events rather than working time, so it has no work calendar and no time format, and it exports to XLSX and CSV. See Transition Count: how many times statuses change.

How do I configure a gadget's project, period and chart type?

Open the gadget menu on the dashboard and choose Configure (the gear). The form holds Project, Epic, Sprint, Assignee, Period (a preset or a custom range), Time format, View (Chart or Table) and Visualization (Donut, Bar or Area). Press Save — only people who can edit the dashboard can save, and the saved configuration is what every viewer sees. Viewers can still re-cut the card with the chips and the inline chart switch for their own session. See Jira dashboard gadgets.

How do I send a Jira report by email on a schedule?

Set the filters on a report page first, then open Scheduled Reports in the app sidebar and press New schedule. Give it a name, pick one of the five reports, choose Daily, Weekly or Monthly with a start date, a start time and a time zone, and type up to 10 recipients — nobody is added implicitly, not even you. The filters are frozen when the schedule is created, so changing them later means creating a new schedule. Every run mails an XLSX, attached when the file is 7 MiB or smaller, and appears in your Export History. See Scheduled reports by email.

How do I download an export from Export history?

Open the Export menu in the report controls and pick MS Excel Report (.XLSX) or Plain Text Report (.CSV); in chart mode, on any of the five reports, there is also Chart Image (.PNG). The file is built in the background, so you can keep working. Open the Export history panel, wait until the status turns to Success, and click the file to download it. Your 20 most recent exports stay in the list — scheduled runs are in the same list — and you can delete any of them. See Export reports to Excel (XLSX), CSV or PNG.

Who can open the reports?

Any user whose Jira group has the Report grant in Access Settings; the same grant opens the Scheduled Reports page. Jira admin groups always have access. Beyond that, every Jira read runs as the person viewing the report, so a report shows only the issues that user can already open in Jira.

Does the app change my issues?

The app writes to Jira only when you act. Saving the Edit issue dialog changes an issue; saving a gadget's configuration stores it as a property of that dashboard item. Reports and gadgets never modify issues on their own.

Can different teams use different work schedules?

Yes — create a calendar per team (each with its own business days, hours, time zone and holidays) and let every user pick theirs in the report controls. The pick is personal and remembered: it applies to every report that measures time — Time in Status, Assignee Time, Time to Resolution and Time in Changes — and to that user's dashboard gadgets, and it leaves everyone else's numbers alone. Transition Count counts events rather than hours, so no calendar changes it.