Stintwise

Documentation

Support for this app is written, not conversational. Every message the app can show links to a heading on this page, and every heading answers one question completely. There is no chat widget and no phone number, and that is a deliberate design choice, not an oversight: the app is built and maintained by one person, and written answers scale where conversations do not.

How the numbers are calculated

Cycle time starts the first time a work item enters one of your Started statuses, and ends the last time it enters one of your Done statuses. A work item created in a Started status enters it when it is created, unless its status history starts before that (see below). If it leaves the Done set again — reopened, sent back for review — the end is cleared and the next entry into Done becomes the new end.

Lead time starts when the work item was created and ends at the same point cycle time ends. Normally it is therefore at least as long as cycle time.

There is one case where it is not, and the tile shows it rather than hiding it. Some work items have a status history that starts before their creation date — imports and bulk migrations do this routinely, because the migration preserves the original transition timestamps while stamping created at the time of the import. When that happens the work was already in progress before the date Jira calls its creation, so lead time — measured from creation, as above — comes out shorter than cycle time. Open the work item in the drill panel and you will see the pre-creation stretch as its own row, which is where the difference went.

There are four ways a lead time can be missing, and in each the cell is left blank rather than filled with a zero, and the work item is left out of the lead percentile:

Counted time is elapsed time minus anything excluded. With Exclude weekends on, Saturdays and Sundays contribute nothing. With a Public holidays region chosen, that country's public holidays, as listed for the whole country, contribute nothing either. A holiday kept only in some provinces or states is not in the list and counts as working time: in Canada, Victoria Day, Thanksgiving, Remembrance Day and Boxing Day; in the United Kingdom, the Summer bank holiday; in Australia, the King's Birthday and Labour Day. A few days on the list are not kept everywhere: in the United States, Columbus Day, which some states, California among them, do not keep, and Washington's Birthday, which a few states keep on another day or not at all; in the United Kingdom, Easter Monday, which is not a bank holiday in Scotland; in Switzerland, where only 1 August is a federal holiday, Good Friday, Easter Monday, Whit Monday and St Stephen's Day, which some cantons do not keep. Holidays are removed only with Exclude weekends on, so a holiday that falls on a weekend removes nothing more on that day. Where a country gives a weekday off in its place, some lists include that substitute day, and it is removed: in the United States, Friday 3 July 2026 for Independence Day; in the United Kingdom, Australia and New Zealand, Monday 28 December 2026 for Boxing Day. Canada's list has no substitute days.

One day means 24 hours of counted time, not one calendar day. A work item that starts Friday at 16:00 and finishes Monday at 10:00, with weekends excluded, counts 18 hours — 8 on Friday evening and 10 on Monday morning — and excludes 48.

Percentiles use the nearest-rank method: the 85th percentile of ten values is the ninth value when sorted, not an interpolation between the eighth and ninth. This is why a percentile is always a real work item's real duration and never a number nothing achieved.

What a By status segment averages

Each segment is the counted time all charted work items spent in that status during their cycle time, divided by the number of charted work items, so the segments add up to the mean cycle time printed at the end of the bar. Time in a status outside a work item's cycle time is not in any segment: the rows marked lead time only, from before work started, and the rows marked in neither total, from before an imported work item was created.

Click a segment to see the work items that spent cycle time in that status. Their rows for it that are marked neither lead time only nor in neither total add up to the segment's total, which is divided by every charted work item, not only by the ones listed. The segment names that divisor; the panel names it too, and counts the work items listed. The values on the segments are tenths of a day rounded as a set, so that they add up to the mean at the bar's end; a segment can therefore read a tenth more or less than its own mean, which the panel states to the hundredth.

Why the totals do not match a calendar

Because a day here is 24 counted hours. Three counted days can span a fortnight if most of that fortnight was weekends and holidays. The drill panel shows the arithmetic for any work item, line by line, including what was excluded and why. Its times are shown to the minute, and each line's minutes are rounded as a set so that a work item's lines add up to its totals, so a line can differ by a minute from its exit time minus its entry time; the CSV export has the seconds.

The reconciliation line

Under the chart title is a line reading, for example, 142 work items charted · 11 excluded, followed by the reasons. Those two numbers add up to every work item that counts as completed in the selected range, by the rule below, with two exceptions the chart tells you about when they apply: work an organisation's app access rule keeps from the app's searches (the app is not allowed to read), and, past 10,000 search results, counts that are Jira's estimate (over the 5,000 item cap). Nothing else in that population is dropped silently, with one exception the app cannot see: a work item imported straight into a Done status and reopened since, because Jira's search does not know the status it was imported in.

The population is not everything the filter matches. A filter can match thousands of work items; this chart is about the work that finished in the window you chose — see Date range. Jira is asked, as you, for the work items your filter returns for you that entered one of your Done statuses during the range, or were created during it and are in one of them now: the same work items the filter would list for you in Jira. The second part also returns work created in the range and finished since it ended, which the app reads and then leaves out. Nothing else is read at all.

A work item it reads counts as completed in the range when:

An entry into Done is a move into one of your Done statuses from a status that is not one, or the creation of a work item in a Done status. A move from one Done status to another, such as Done to Closed, or the Done to Done change Jira records when finished work moves to another project, is not a new entry: the work item was already done, and keeps the completion date it had.

Other work items the search returns are discarded before counting, apart from the exceptions below. Discarded work includes work that finished inside the range, was reopened, and was completed again after it, which is judged by its latest completion, and work whose only move into a Done status in the range was from another Done status. Work that never finished is not read at all: it has no end, so it has no cycle time to chart. To see work in progress, use your board.

The exceptions, stated rather than guessed around. For four kinds of work item the app cannot tell when the item finished, so it counts them under their own reasons rather than dropping them:

So a few of these may be items last completed after the range, which the rule above would have discarded had the app known.

Click any reason to see exactly which work items it covers, except over the 5,000 item cap, which has no list. Click any bar, dot or segment to see the arithmetic behind it. On the scatter, time runs across the chart's whole range, dated at both ends, and a dot drawn on top of others opens every work item at that spot, its heading saying how many more there are. Export ledger (CSV) gives you the same figures as a file, one row per status segment plus one row per work item plus closing rows restating the 85th percentiles of cycle and lead time — so you can check the chart in a spreadsheet without trusting this app at all.

The CSV format

Fifteen columns, RFC 4180, UTF-8 with a byte-order mark so Excel reads the characters correctly. Every hours figure has exactly four decimals, a full stop as the decimal mark and no thousands separator: 4.6157, 0.0000. If your spreadsheet uses a comma as the decimal mark or a semicolon as the list separator, double-clicking the file will not read it correctly. Import it instead:

Skip that step and a spreadsheet may read 1.2500 as something other than one and a quarter hours, or leave it as text. A work item key that reads like a date, such as MAR-12 or DEC-25, can also become a date when the file is opened by double-clicking it, or imported with that column left to be detected; MAR-1 and MAR-2026 can then become the same date. Setting issue_key to Text keeps every key as Jira wrote it.

To compare an hours figure with the minutes on the chart or in a panel, round it to the second first, ROUND(hours * 3600, 0) / 60, then to the minute. Both are roundings of the same whole second, so rounding the four-decimal hours straight to minutes lands a minute away about once in 180 values.

Any text that begins with =, +, -, @, a tab or a carriage return, after any spaces, is written with a leading apostrophe, so a spreadsheet shows it as text instead of running it as a formula. A field containing a comma, a semicolon, a tab, a quote or a line break is quoted. A spreadsheet that splits the file on semicolons or tabs ignores those quotes and still splits such a field across cells — the Polish holiday Święto Państwowe; Święto Pracy lands in two, and every cell after it moves along one — so an apostrophe is also written after each comma, semicolon, tab or line break inside a field that one of those characters, or a quote, follows, spaces or not. Split on commas, semicolons, tabs or line breaks, with or without trimming spaces, no piece of a field runs as a formula; to keep the columns in place, import with the comma as above.

Each work item contributes one segment row for each stretch between its status changes, so a status it entered twice has two rows, and a stretch that spans its creation date is split there into two rows; then one issue_total row. A work item the banner lists without the app having read its history, one not read before the time limit or one the app is not allowed to read, has its issue_total row only. Work items over the 5,000 item cap have no rows. A segment row's excluded_reason names every calendar that removed time from it: weekend, then each public holiday as holiday:, the country code and the holiday's name, joined by +, as in weekend + holiday:DE:Tag der Deutschen Einheit. A work item still open, or moved back after Done, has a last row that has not ended: its left_at is the end of the chart's range, which is the start of the day the chart was built, in the gadget's time zone, not a status change. If the work item changed status since then, its last row ends at that change instead, and the status it is in now has no row. Its hours grow once a day, with each day's chart, not at each rebuild. Neither total uses that row. The file ends with two closing rows, a cycle_time row and a lead_time row, each holding that line's 85th percentile, the number of work items it was computed over, and the number it left out. The chart's 50th and 95th percentile rules have no closing row of their own: compute them from the issue_cycle_time_hours column of the charted rows, by the same nearest-rank rule.

Two closing rows because the two lines are drawn over different populations, and a number you cannot reproduce is the thing this app exists to avoid:

A list exported from a panel, with Export this list (CSV), holds only the work items listed, and its two closing rows are computed over those alone: their percentiles and counts belong to the list, not to the chart. Only Export ledger (CSV) reproduces the chart's numbers.

The identity that must always hold: for any work item, the sum of counted_hours across its segment rows where in_cycle_time is true equals its issue_cycle_time_hours, to the fourth decimal. If it ever does not, the file is wrong and you should say so. The same holds for in_lead_time and issue_lead_time_hours; each closing row recomputes, to the fourth decimal, from the population named above; and on every segment row, counted_hours is elapsed_hours minus excluded_hours.

The figures are rounded so that all of this is exact. Each stretch between two status changes is first measured in whole seconds, and a work item's cycle and lead time are built from those. Its two totals are those times rounded to the nearest ten-thousandth of an hour (0.36 seconds), and its segment figures are rounded up or down, as a set, to add up to them. Jira records status changes to the millisecond, and entered_at and left_at show those milliseconds, so a segment's elapsed_hours can differ from its left_at minus its entered_at by up to 0.00024 hours (0.86 seconds): up to half a second from the whole-second measurement, the rest from the rounding. Where both timestamps are whole seconds, the difference is under 0.0001 hours.

Why work items are excluded

Ten reasons, and the chart names whichever applies.

still open

Jira returned this work item because its history shows it entering one of your Done statuses during the window, but the history the app read has no completion among your Done statuses selection that is still in place: none by the rule for what counts as completed. Without one there is no end, so there is no cycle time. It is counted in the excluded total and nowhere else.

This should be rare, because work that has not finished is never returned in the first place — see the reconciliation line. If you see it, open the work item's History tab in Jira and compare the statuses it moved through with your Done statuses selection.

never entered a started status

The work item reached Done without ever being in a Started status — typically closed as a duplicate, or moved straight from the backlog. There is no start, so there is no cycle time. A work item created in a Started status is not one of these: its cycle time starts when it was created. The exception is a work item whose status history in Jira starts before its creation date: the app cannot tell when its work started, so unless it later moved into a Started status it is counted here. Lead time is usually still available for these. Of the reasons described above, three can leave it blank here: the work item's whole status history predates its creation, so its lead window is empty; the calendar you chose excluded every hour of that window, see how days are counted; or it was finished the moment it was created.

If you see many of these, your Started statuses selection is probably too narrow. Check the edit view against the statuses your team actually uses.

transitioned backwards after Done

The work item entered a Done status and then left it again, and has not re-entered one. Its end has been cleared, so it is treated as still in flight. When it is completed again it will appear in the chart with the later completion date.

transitions sharing a timestamp

Two or more status changes carry the identical timestamp, so the order of events is genuinely ambiguous and any cycle time computed from them would be a guess. This is almost always caused by an automation rule or a bulk edit moving items through several statuses at once.

The app refuses to guess. If this affects many work items, the automation is writing history that cannot be measured, and the fix is in the automation rule rather than here.

finished before they started

The end is earlier than the start. Jira's own history cannot cause it, because the app puts status changes in time order before measuring, imported or backdated ones included. It happens when one status is chosen both under Started statuses and under Done statuses in the settings: choose each status for one of the two. The work item is excluded rather than charted as a negative duration.

counted to zero

The work item has a valid start and end, but every hour between them was excluded by the calendar you chose — it was started and finished within a single weekend, or inside a public holiday. Its counted time is zero, which is not a meaningful point on a cycle-time chart.

Whichever calendar removed the time is the one to change: turn off Exclude weekends, or clear the holiday region. The exported CSV tells you which — the excluded_reason column on that work item's segment rows names it.

This cause means the calendar removed the time, and nothing else. A work item started and finished less than half a second apart — an automation rule that moves it through a Started status and on to Done in one run — is charted, at zero, in the first bucket. Half a second or more counts as one second: on a working day it is charted at that second, and on a day your calendar excludes it is counted to zero here. One created and closed in one run without ever being in a Started status never started, and is counted under never entered a started status. It is a real measurement and hiding it would tell you nothing about work your team is actually doing that way.

incomplete history in Jira

Jira did not give the app this work item's complete change history, so its timeline cannot be reconstructed. That happens in these ways:

The chart says so rather than charting a partial timeline as if it were whole.

Because the missing part may be exactly where the item finished, the app cannot tell whether it was last completed inside the range or after it. It counts the item here rather than guess; see the reconciliation line.

not read before the time limit

The app ran out of time before it could read this work item's history, so it knows nothing about when the work item started or finished. Jira withheld nothing. This happens only when history is read one work item at a time.

A build may read for at most ten minutes. Forge stops a build outright at fifteen, and a stopped build reports nothing at all, so the app stops first and reports what it has: the work items it read are treated as usual, and the ones it did not reach are listed here rather than left out. The note under the banner says so too. The app cannot tell when an unread item was last completed, so a few items listed here may have been completed again after the range; see the reconciliation line.

Each build sends at most ten requests a second, so ten minutes covers at most about 6,000 work items. Up to three builds run at once on a site, each at its own ten a second. It covers fewer when Jira answers slowly, when a work item's history needs more than one request, or when Jira asks the app to slow down: a request Jira refuses is retried after the pause Jira asks for, and the pause counts against the ten minutes. If Jira asks for a pause longer than the time left, the app does not wait; it stops there. At 0.3 seconds per request it is about 2,000. To get every work item charted, narrow the saved filter or shorten the date range so that fewer work items need reading.

the app is not allowed to read

Your search returned this work item, so you can open it, but Jira would not let the app read it: an organisation administrator can keep Marketplace apps away from some projects with an app access rule. The app knows nothing about it beyond its key, so it counts it here and lists it by key rather than leaving it out. To have it charted, ask an administrator whether an app access rule covers its project.

An app access rule can also hide work from the searches the app makes for you. When Jira says the site has content the app may not read, the chart says so under the banner: work in those projects may be missing from the chart without being counted anywhere.

over the 5,000 item cap

More than 5,000 work items in this filter completed in the range, or Jira's search for them returned more than 10,000. The app keeps the 5,000 with the most recent completion: those with no other reason to be excluded are charted, the rest keep their own reasons, and any further completions are counted here. A work item the app read that has no completion in the range, such as one reopened after finishing, or whose history Jira withheld, keeps its own reason and is never counted here. Search results past the first 10,000 are counted here without being read, whatever they would have turned out to be; how many there are is Jira's estimate, so the chart says its counts can be too high or too low. Narrow the saved filter — by project, by date, or by team — to bring the whole set into range.

The work items over the cap are not kept, so this reason is plain text on the banner rather than a link: there is no list to open, and the CSV export has no rows for them. Only the ids of those the cap dropped past the 5,000 it keeps are kept, for the check, each time the chart is shown, that you can still open every work item it counts (see Who sees what); search results past the first 10,000 are never read, so not even their ids are known.

The completion date used here is the real one, read from each work item's history — not the date it was last edited. A ticket closed in March and re-labelled yesterday still counts as a March completion.

One limit worth stating: this holds while Jira's search for work items in your filter that entered a Done status during the range returns up to 10,000. Beyond that, the app cannot read every work item's history within one build, so it falls back to Jira's own ordering — which is by last edit — to decide which 10,000 to examine. If your filter is that large, the honest advice is to narrow it; the chart will be both faster and exactly right.

Messages the app can show

That saved filter is not available

The saved filter was deleted, or it is no longer shared with you. Jira gives the app the same answer in both cases, so the app cannot tell you which one it is. Renaming a filter does not cause this. Open the gadget's own menu at the top right of the tile, choose Edit, and pick a filter you can open, or ask the filter's owner to share it with you.

Jira rejected the filter query

The saved filter contains JQL that Jira will not run for you — usually a field or a project that has since been removed, one you cannot see, or another saved filter it refers to that you cannot open. Open the filter in Jira and fix the query there; the next view then builds the chart from the fixed query straight away. Until it is fixed, each view runs the search again and shows this message again. This app cannot edit filters. It does add conditions of its own when it runs the filter for you: the Done statuses chosen in this gadget and the date range, as filter = <id> AND (status CHANGED TO (<Done statuses>) DURING (<range>) OR (status in (<Done statuses>) AND created >= <start> AND created < <end>)).

Who sees what

Your chart is built from the work items the saved filter returns for you in Jira, searched as you, and from nothing else: the app then reads the status histories of exactly those work items. So it lists only work items you could open when it was built, and nobody else is shown it. Colleagues who can open different work items each see a chart of their own, and their numbers differ where their access does. Each chart is built at its viewer's first view of the day, from Jira as it is then, so two people who can open the same work items see the same numbers unless something changed between their first views — a work item reopened, or an edit that changes what the filter returns — and then until the next day. A filter that uses currentUser(), lastViewed or another part of JQL that Jira answers differently for each person means, for each person, what it means to them in Jira.

Before your chart, a drill panel or an export is shown, Jira is asked, as you, how many of the chart's own work items, named by their ids, you can open. If you have lost access to any since it was built, it is built again from a fresh search of yours. Jira describes these counts as estimates that may miss the latest changes, so access lost a moment ago can be noticed late; an answer that lets you see the chart is reused for up to five minutes.

Jira refused access

Jira answered that a request was not allowed (HTTP 401 or 403). The one cause Jira's documentation gives for that answer is credentials that were missing or not accepted. When Jira refused the build itself, the first view of the dashboard at least ten minutes after the failure builds the chart again, and refreshing sooner shows this message again; when it refused the check made as you, a refresh asks again straight away. If it keeps happening, ask a Jira administrator to check that the app is still installed and allowed to read the site.

A filter you cannot open gives a different message. Before any chart is shown, the app checks, as you, that you can open the saved filter the chart is built from. When Jira says you cannot, you see That saved filter is not available, and no chart.

Your chart is your own: it is built from the work items the filter returns for you, and nobody else is shown it. See Who sees what, and, in full, Who can see a chart.

Reading the change history

Your first view of the day builds your chart. Jira is asked, as you, for the work items your saved filter returns for you that entered one of your Done statuses during the range, or were created during it and are in one of them now; the app then reads their status histories. The counter shows how many histories it has read out of how many it will read, which is at most 10,000 (see over the 5,000 item cap). It moves once per 1,000 work items, so a smaller filter shows 0 until it is done.

Each person's chart is built for them: on their first view each day, on the first view after an app update that changes how charts are built or stored, and on the first view after the filter's query changes. Builds on one site run three at a time, so at a busy moment yours may wait its turn; the tile waits with it.

How long it takes depends on how many work items match, and on whether Jira lets the app read their histories in bulk; see read one work item at a time. If the build has been running for five minutes without finishing, the tile says so.

This is taking longer than expected

The first build for a configuration reads the full change history of every matching work item, and that did not finish within five minutes. Refresh the dashboard to try again. If it recurs, the filter is probably very large — narrowing it is the reliable fix.

Jira is rate limiting or unavailable

Jira kept turning the app's requests away, or asked it to pause for longer than a chart build may run. There are two usual reasons:

Either way it is temporary. Try again later.

While a chart is being built, a retry waits at least as long as Jira's Retry-After header asks, and longer when the app's own spacing between attempts — two seconds, doubling each time, give or take a little — is longer. The one exception is a wait longer than the time the build has left: Forge stops a build after fifteen minutes and records nothing when it does, so the app does not start such a wait. When history is read one work item at a time, the read stops there and lists what it did not reach as not read before the time limit. The check whether Jira keeps content from the app is skipped instead, and the chart then says nothing about it. Any other read ends the build with this message. A Jira quota can ask for a wait of half an hour or more.

Retries on the read that checks you can open the saved filter are shorter, because a request from the tile has only seconds to answer. If they still fail, the tile shows this message and asks again when you refresh the dashboard.

History was read one work item at a time

Some Jira instances do not allow the bulk change-history endpoint. When that happens the app falls back to reading each work item's history individually. Every history it reads is read in full, so for those work items the numbers are exactly the same — the build just takes longer.

Reading one at a time is slow enough that a large filter may not finish within the build's time limit. Any work item the app did not reach is excluded and listed on the banner as not read before the time limit, and the note under the banner then says how many, in place of "The numbers are unaffected". When that note does not appear, nothing was missed.

"In full" is meant literally: the per-item endpoint cannot be asked for status changes only, so Jira sends every change to every field. The app keeps the status changes and discards the rest in memory. Nothing extra is stored — see the privacy page.

This is different from incomplete history, which is reported separately and lists the affected work items with a reason. See work items with incomplete history.

The counts are estimates

When your search returns more than 10,000 work items, the app reads the first 10,000 — the most recently edited first — and counts the rest over the 5,000 item cap by Jira's estimate for you, without reading them. The note under the banner says so. Those unread work items are counted whatever they would have turned out to be, some may have been reopened or still be open, and the number is Jira's estimate, so the number over the cap and the number excluded can be too high or too low. The number charted, and the numbers never entered a started status, transitions sharing a timestamp, finished before they started and counted to zero, can be wrong either way too: the 5,000 work items the app keeps are chosen from the 10,000 it read, so a complete read could have kept others. The numbers still open, transitioned backwards after Done, incomplete history, not read before the time limit and not allowed to read can only be too low: those work items never compete for the 5,000 places, so their counts only miss what was not read.

Narrow the saved filter — by project, by date, or by team — until the note disappears. The counts are then exact.

The chart was redrawn

When you click a bar, a dot or an exclusion reason, or export, the app reads the list from the stored copy of the chart the tile is showing. That copy can be replaced while the tile is open: a chart is built afresh on your first view each day, on the first view after an app update that changes how charts are built or stored, and when the filter's query changes; a stored chart the app finds damaged is dropped and built again, and so is one listing a work item you can no longer open. The list would then belong to a different chart from the number you clicked, so the app draws the tile again from the current copy and says which of two things happened:

If the new copy is still being built, the tile shows its progress first.

A request did not complete

Five messages mean one request from the tile or the settings did not complete:

Usually the connection dropped, or Jira or Forge did not answer in time. Nothing already on screen is affected: do what the message says and try again. If the same request keeps failing after you reload the dashboard, it is a bug worth reporting, and the one detail that identifies it is the saved filter the gadget points at.

This app is not licensed

The trial has ended or the subscription has lapsed. Start a trial or subscribe from the Atlassian Marketplace listing; the chart returns immediately afterwards, and no configuration is lost.

Something went wrong

The app hit an error that no message above describes, or it could not read its own stored data.

Stored charts belong to you, the gadget's settings, the filter's query and the day, not to the gadget. Removing the gadget and adding it again with the same settings on the same day brings back the same stored result, including a failure. Changing any setting, or the filter's query, starts a fresh build straight away, and an app update that changes how charts are built or stored starts one on the next view. Otherwise your chart is built afresh on your first view each day, and a stored chart the app finds damaged is dropped the next time it is read, so the view after that builds it again.

If it keeps happening after all that, it is a bug worth reporting, and the one detail that identifies it is the saved filter the gadget points at.

Configuration

Six controls, and there will never be a seventh — every additional setting is another way to get a number you cannot explain.

Saved filter. Searchable, drawn from your own Jira saved filters. JQL cannot be typed here on purpose: a filter is shared, reviewable and owned by someone, whereas JQL pasted into a gadget is none of those things. When no saved filter you can see has a name containing what you type, the settings say so: save the search as a filter in Jira first, or ask the filter's owner to share it with you.

Started statuses and Done statuses. Preselected from Jira's own status categories, which is right for most teams. Change them if your workflow does something more specific. A status is matched by its id, not its name, so renaming it in Jira changes nothing on the chart's numbers; each is shown under the name Jira gave it when the app last read the site's status list, at most an hour before the chart was built. A status added later under a chosen name, or renamed to one, such as a new project's own Done, counts in charts built from an hour after the change: builds share the site's status list for an hour. A chart built within that hour keeps its numbers for the rest of its day.

Date range. Filters on completion date, not creation date. A work item completed inside the range is charted however long ago it started. The range is the chosen number of days before today, in the gadget's time zone, so today's completions are charted from tomorrow, and a chart does not change during the day.

So a filter can match hundreds of work items and still chart nothing: if none of them completed inside the selected range, there is nothing to measure. That is not an exclusion — those work items were never candidates — and the tile says so rather than listing causes it does not have. A longer range, or a filter that covers finished work, is the usual fix.

Exclude weekends. Off by default, so the first chart you see counts plain elapsed time and nothing is quietly removed from it. Turn it on and Saturdays and Sundays stop counting.

Public holidays. Available only while weekends are excluded, because a holiday is a kind of non-working day; excluding holidays while counting Saturdays produces a number nobody can explain. Twenty countries are available, covering 2015 to 2032.

More saved filters match than are listed

The list under the filter box holds the 50 saved filters you can see whose names contain what you typed, the most favourited first. When more than 50 match, the app also looks for a filter named exactly what you typed, among the first 250 whose names contain it, and lists it first. If that lookup did not read every one of them, or failed, the note says a filter of that exact name may not be among those listed. Type more of the name to narrow the list.

Time zone

The time zone is frozen when the gadget is configured, taken from the person configuring it. It decides where each day begins, and so the range, which is the same for every viewer wherever they are.

Privacy

The app stores no issue content and no account id. It reads status change history to compute durations, builds each person's chart once a day, and every chart is deleted within 73 hours of its build. A chart is marked as yours by a key made from your account with a secret the app keeps, which cannot be turned back into your account without it; the key goes when the chart does. It never asks Jira for summary text, descriptions, comments or assignees, and never stores them. Jira does attach the identity of whoever made each change to every history record, and when history is read one work item at a time it sends the whole history. It also sends the saved filter's owner and sharing with the filter, and the configuring person's whole profile with their time zone. The app keeps what it needs and discards the rest in memory as the response is read. The full list is on the privacy page.

Who can see a chart. A chart is built for one person, from the work items the saved filter returns for them in Jira, searched as them, and only they are shown it. The app then reads, as itself, the key, creation date, current status and status history of exactly those work items, and asks Jira nothing else about them; when history is read one work item at a time, Jira sends each one's whole change history and the app keeps only the status changes. Before a chart, a drill panel or an export is shown, the app checks, as you, that you can open the saved filter, and asks Jira, as you, how many of the chart's own work items, named by their ids, you can open; if you have lost access to any since the chart was built, it is built again from a fresh search of yours. So a chart never lists a work item you could not open when it was built, and access you lose is noticed at the next view, or within five minutes of it. Jira describes these counts as estimates that may miss the latest changes. Work items beyond the first 10,000 your search returns are counted, by Jira's estimate for you, but never listed.