Documentation — Dwell for Jira

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 three 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:

The whole history predates creation, so the lead window is empty. Cycle time is still measured, from the first move into a Started status: the creation date cannot be its start, because the history begins earlier. A work item whose only Started status is the one its history begins in has no such move, so it is counted as never entered a started status.
The calendar you chose emptied the window. With Exclude weekends on, a work item opened and closed inside one weekend has a lead window every hour of which is excluded. Zero would read as a measured zero-hour lead for something that was open for a day, so nothing is stated instead. Turn off Exclude weekends, or clear the holiday region, and the same work item has a lead time again.
Jira withheld part of the history. For a work item counted under have incomplete history in Jira, the part the app could not read may be exactly where the work item finished, so no lead time is stated. Its rows are still in the file, in neither total.

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 contribute nothing either.

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.

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.

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 always add up to every work item that counts as completed in the selected range, by the rule below. Nothing in that population is dropped silently.

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. The app asks Jira only for work items in your filter that entered a Done status during the window, looking two days wider at each end so that a time-zone offset cannot hide one. Nothing else is read at all.

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

it is in a Done status now, and its most recent entry into Done falls inside the range; or
it has been reopened and is not in a Done status now, and any of its entries into Done falls inside the range. It appears in the excluded count as transitioned backwards after Done: it did finish in your window, and dropping it silently is exactly what this chart exists not to do.

Other work items the search returns are discarded before counting, apart from the exceptions below. Discarded work includes work that finished only in the two days either side of the range, and work that finished inside the range, was reopened, and was completed again after it; that work is judged by its latest completion. 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 three kinds of work item the app cannot tell when the item finished, so it counts them under their own reasons rather than dropping them:

items whose history it could not read in full — not read before the time limit and incomplete history in Jira;
items whose history has no entry under the names in your Done statuses selection — still open;
when Jira's search returns more than 10,000 work items, the ones beyond the first 10,000 it returns, which are counted as over the 5,000 item cap without being read.

So a few of these may be items that finished in the two days just outside 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. 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:

Excel: Data › From Text/CSV, choose Comma as the delimiter, then Transform Data, select the hours columns and use Change Type › Using Locale with the type Decimal Number and the locale English (United States).
LibreOffice Calc: in the Text Import dialog, tick Comma as the only separator and set Language to English (USA).

Skip that step and a spreadsheet may read 1.2500 as something other than one and a quarter hours, or leave it as text.

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 per status it passed through, then one issue_total 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:

cycle_time closes over the rows where charted is true.
lead_time closes over the rows where charted is true or exclusion_cause is NEVER_STARTED, ignoring any row whose issue_lead_time_hours cell is blank — a work item that never entered a started status has no cycle time but usually does have a lead time, and a blank cell means the app is declining to state one for the reasons above. The chart states that population beside the number too, so your count should match its N exactly.

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

Nine 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, or in the two days either side of it that the search also covers, but the history the app read has no such entry under the names in your Done statuses selection. 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, two can leave it blank here: the work item's whole status history predates its creation, so its lead window is empty, or the calendar you chose excluded every hour of that window; see how days are counted.

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. This cannot happen through normal use of Jira; it comes from imported data or backdated transitions. 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 genuinely opened and closed within the same second — an automation rule that creates and closes in one run — is charted, at zero, in the first bucket. 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 two ways:

The history is very long. Jira reported more change history than it returned.
Jira refused the work item. When history is read one work item at a time, Jira can answer that a work item its search listed moments earlier is not found, or not open to the app. That usually means it was deleted, or hidden by issue security, while the chart was being built.

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 finished inside the range or in the two days either side, which the search also covers. 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 search looks two days wider than the range, and the app cannot tell when an unread item finished, so a few items listed here may have finished just outside the range; see the reconciliation line.

The app sends at most ten requests a second, so ten minutes covers at most about 6,000 work items. 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.

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. 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.

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, or in the two days either side, 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 — usually a field or a project that has since been removed. Open the filter in Jira and fix the query there. The first view of the dashboard at least ten minutes after the failure builds the chart again, with the filter as it is then; refreshing sooner shows this message again. This app cannot edit filters. It does add one clause of its own when it runs the filter's query: the completion window, which names the Done statuses chosen in this gadget and the date range.

This filter depends on who is viewing it

The saved filter, or a saved filter it refers to, uses a JQL function that Jira answers differently for each person who runs it, such as currentUser(). This chart is built once for the gadget's settings and every viewer sees that one result, so there is no single answer to give. Built as the app, the filter would match the app's own account, which is almost always nothing, and the chart would show a confident zero. The app refuses the filter instead: the settings will not save it, and a gadget already set up with it shows this message and builds nothing.

The functions refused are currentUser(), currentLogin(), lastLogin(), issueHistory(), workItemHistory(), watchedIssues(), watchedWorkItems(), votedIssues(), votedWorkItems(), myApproval(), myPending(), myPendingApproval(), projectsWhereUserHasPermission(), spacesWhereUserHasPermission(), projectsWhereUserHasRole() and spacesWhereUserHasRole(), and projectsLeadByUser(), spacesLeadByUser() and componentsLeadByUser() when they are called without a user. Jira accepts both the older names and the ones it has used since issues became work items and projects became spaces. A function named inside quoted text is not a call and does not count.

A filter can refer to another saved filter, as in filter = 12000 or filter = "Team base" (Jira also accepts request, savedFilter and searchRequest for filter), and then it runs that filter's query too. So the app reads, as you, each saved filter it refers to and the ones those refer to, up to five levels, and refuses the filter if any of them uses one of these functions. For a filter referred to by name, it looks among the first 250 saved filters you can see whose names contain that name. A referred filter you cannot open, or that is not among those 250, is not checked.

Open the gadget's own menu at the top right of the tile, choose Edit, and pick a filter that names the people, groups or projects it means — assignee in membersOf("my-team") instead of assignee = currentUser(), for example — or change this filter in Jira.

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.

The check is per filter, not per work item. The chart itself is built once per configuration and shared by everyone viewing that gadget, which is what makes two colleagues see identical numbers — so the numbers cover every work item the saved filter returns that completed in the range, not a per-viewer subset. If a filter spans a project some viewers cannot browse, put the gadget on a dashboard shared with the right people, or narrow the filter. This is described in full under Who can see a chart.

Reading the change history

The first view of a new configuration builds its chart. The app asks Jira for the work items your saved filter matches that entered one of your Done statuses during the range, or in the two days either side, 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. This happens once per configuration. The result is stored and shown to everyone viewing a gadget with the same settings. It is built afresh once it is 24 hours old, and on the first view after an app update that changes how charts are built or stored.

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 not finished after five minutes, 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:

Jira's quota for this app is used up. Atlassian limits how much each app may ask of Jira in an hour, and by default that limit belongs to the app as a whole: one quota, shared by every Jira site that has the app installed. A busy hour elsewhere can use up what your chart needed. The quota resets at the top of each hour (UTC).
Your Jira site is briefly unavailable. That usually clears within minutes.

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. 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 incomplete

A build pages through at most 100 pages of Jira's search results, of up to 1,000 work items each; Jira may send fewer per page. When the search still has results after the last page, the app never sees them, and they are in no count at all. The note under the banner says so. The number excluded, and the number over the 5,000 item cap, can then be smaller than the real ones, never larger. The number charted, and the number for each other reason, can be wrong in either direction: the 5,000 work items the app keeps are chosen from the part of the search it saw, so it can chart some, or exclude them for a reason of their own, that a complete search would have left over the cap, and miss some that it would have charted.

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

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 once it is 24 hours old, and on the first view after an app update that changes how charts are built or stored, and a stored chart the app finds damaged is dropped and built again. 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:

The chart was rebuilt and what it shows has changed, so it has been redrawn. The new copy shows different numbers or settings. Most often the range has moved: it always ends when the chart is built, so a chart rebuilt a day later covers a range a day later, and work items that finished at its far edge drop out even when nothing in Jira changed. The work items in Jira may also have changed, or an app update may have changed how charts are built. Read the new chart and click again.
The stored copy of this chart was rebuilt. The numbers did not change; click again. Nothing on the tile changed, so the same click now opens the list.

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

A request did not complete

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

The export failed. No file was saved.
The next page could not be loaded. The rows already in the panel are unaffected.
Your settings could not be saved. The gadget keeps the settings it had.
Filter search failed. The list of filters could not be fetched.

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.

If a build failed, refreshing straight away shows this message again. The app waits about ten minutes before building the same settings again, so that a failing configuration is not rebuilt on every view. Refresh after that.
If stored data could not be read, a refresh a minute later is enough. Forge limits how much an app may read from its storage each minute.

Stored charts belong to the gadget's settings, not to the gadget. Removing the gadget and adding it again with the same settings brings back the same stored result, including a failure. Changing any setting 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 a chart is built afresh once it is 24 hours old, 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.

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.

Date range. Filters on completion date, not creation date. A work item completed inside the range is charted however long ago it started.

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.

Time zone

The time zone is frozen when the gadget is configured, taken from the person configuring it. Every viewer therefore sees identical numbers regardless of where they are — a dashboard where two colleagues read different figures is worse than no dashboard.

Privacy

The app stores no issue content and no user identity. It reads status change history to compute durations, keeps the resulting numbers for 24 hours as a cache, and deletes datasets that have not been rebuilt for 30 days. 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. Before any chart is shown, the app checks — as you — that you can open the saved filter it is built from. If you cannot open the filter, you do not get its chart.

The chart itself is built once per configuration and shared by everyone viewing that gadget, which is what makes it fast and what makes two colleagues see identical numbers. That means the numbers cover every work item the saved filter returns that completed in the range, not a per-viewer subset. If a filter spans a project some viewers cannot browse, put the gadget on a dashboard shared with the right people, or narrow the filter.

This is a per-filter guarantee, not a per-issue one, and we would rather say so than imply something stronger.