Getting started with Crosstab

Crosstab is five Jira dashboard gadgets, four of them over one grid. You pick two things to break your issues down by. You can also pick a numeric field to add up. The grid is the table: a total in every cell, and row, column and grand totals that reconcile with each other.

The field to add up is optional. Without one, every cell counts issues. That is the only grid a board that keeps no estimates can draw.

The grid works in business projects too: nothing in it needs a sprint or a story point. Either axis can be a select field of your own, such as Client. It cannot be Jira Service Management's Request type, which Jira stores as a field type of its own rather than as a select list. The field to add up can be any number field your issues carry, except Work Ratio, which is a percentage. Crosstab Sprints and the Sprint, Sprint scope and Board column axes need Jira Software.

Jira's own Two Dimensional Filter Statistics gadget answers how many. This one answers how much. When it could not read everything it was asked to, it says so on the grid rather than quietly drawing a smaller number.

Crosstab is on the Atlassian Marketplace. A Jira administrator installs it once for the site, and the steps below are how it then goes onto a dashboard. To look first, the demo runs it on an invented board with nothing to install.

Add the gadget

• Edit the dashboardopen the dashboard you want it on and choose Edit.
• Find Crosstabchoose Add gadget and search for Crosstab. The five are in the list under their names.
• Add onechoose Add gadget on the one you want. Crosstab draws the grid.
• Configure itchoose Edit on the new gadget. Until it is configured, it says so rather than drawing an empty table.

Pick a gadget

One app and one subscription give you five entries in the gadget list:

• Crosstab draws the grid.
• Crosstab Total draws one figure for a filter, and the number of issues behind it.
• Crosstab Change lists what has moved since a grid somebody kept or published: the step in the total, and the cells that moved most.
• Crosstab Chart draws the grid as a chart. It draws bars stacked or side by side, each row as shares of a hundred, or a line for each of its six largest rows.
• Crosstab Sprints draws the last sprints of a filter: what was in each at the start, what was added after, and what was closed by the end.

Each of the five is added to a dashboard on its own. Adding Crosstab does not bring the others with it.

Each has settings of its own. Each can also take them from another Crosstab gadget on the same dashboard: see Start from another Crosstab gadget on this dashboard. Gadgets on one dashboard with the same settings read Jira once between them rather than once each. Every reader still reads with their own permissions.

The grid in a dashboard column offers what a column has room for. Open at page width, under its table, opens the same grid across a whole page. There it has every view, the grid measured against a kept one cell by cell, and a cell followed through several kept grids.

Pick what to count

• Choose the issuesunder Issues from, pick Saved filter or Search.
• Choose the rowspick a field under Down the side.
• Choose the columnspick a field under Across the top.
• Choose what to add uppick a numeric field under Add up, or leave it empty to count issues.
• Savepress Save, and the gadget draws the grid.

The form asks these four questions in this order. The other three have to be answered before anything is stored. Add up decides what a cell holds.

Crosstab Change and Crosstab Chart ask the same four, because they draw the same grid. Crosstab Chart asks one more of its own: which drawing. Crosstab Total asks two: where the issues come from and what to add up. Crosstab Sprints asks what the total asks, and how many finished sprints to draw.

Issues from. Saved filter is chosen from the filters you can already see. Search is a line of JQL you write. One of the two, not both: the form holds the other while it is open, and Save stores only the one chosen. Both are read with your own permissions, not with anybody else's. The grid a colleague sees from the same gadget is the grid their permissions allow.

Down the side and Across the top. These are the two axes. An axis can be anything the site offers that is not about a person:

• issue type, status, status category, resolution and priority;
• project, component, version, label, sprint and team;
• parent, which is the epic an issue sits under;
• a select field of your own, such as Client;
• a date field, drawn by period;
• board column, which is not a field at all but where the issue sits on the board it belongs to;
• sprint scope, on a site that runs sprints.

Sprint scope is the other axis that is not a field. It splits the issues in each sprint into In at the start, Added after the start and Not in the record. Put sprint down the side and sprint scope across the top, and each row is a sprint's plan against the work that joined it later. No issue carries it, so it is read out of each issue's own history. Its figures are the only ones here that do not open a search: Jira has no query that answers it. How the start is decided, and what it costs.

A date field is an axis too: created, resolved, a due date, a date field of your own. Group dates by then asks at what grain: hour, day, week, month, quarter or year. The hour is offered only on a field that holds a moment, since a due date is a day with no time in it.

Left on Whatever fits, the grain is not yours to get wrong. The read cuts at the finest of month, quarter and year that draws no more than twelve of them. So a year of work comes out by month, and four years of it by year. A sentence under the table says when it has chosen. Pick a grain and it is that grain at any span, however many columns that is.

Buckets with nothing in them are drawn rather than skipped. A quiet August reads as a quiet August, not as July running straight into September. Where the span is longer than a table can hold, the grid draws the ones that have issues and says how many it left out.

Add up. The numeric field whose total fills each cell: story points, an estimate, a time field, or any numeric custom field on the site. It can also be Time between two dates, the time from one date on an issue to another, such as from created to resolved. The one exception is Work Ratio. Jira works it out per issue as a percentage, and a sum of percentages is not one. So the form says so where the field would have been. If the site has no numeric field at all, the form says that rather than offering an empty list.

Jira stores a money field as a bare number, so Crosstab takes its currency from the field's name, as in “Budget, $” or “Cost (EUR)”. A field whose name carries no currency is drawn as a plain number.

This one is optional, and leaving it empty is an answer rather than an omission. Every cell then counts issues, and the gadget opens on that view. The views that are about a number are not offered, because there is no number for them to be about.

And where that is empty, read … is a fallback chain, offered once the metric is chosen. Where an issue carries no value in the field above, the read takes this one instead, and the next one after that. A board half-migrated from one estimate field to another is the ordinary case. Without this it reads as half-empty. Only fields measuring the same quantity are offered, so nothing puts seconds behind story points.

Time logged in a period adds up the time logged inside one month rather than an issue's whole Time Spent. Choose it as the metric, then last month, this month or a month you choose. Only issues with a worklog in that month are counted, and each brings only the time logged in it. The month starts and ends at midnight in your Jira profile's time zone; the sentence under the grid names the first and last day and the zone. Where the search does not bring an issue's worklogs with it, they are asked of Jira for that issue on its own, and "How this grid was read" says how many issues needed that. It is offered where the site tracks time, and not on Crosstab Sprints.

Against sets the metric against a second field of the same quantity, such as Time Spent against Original estimate. It is optional and empty to begin with. A Σ field, which already adds up the sub-tasks, is offered only against another Σ field, so no sub-task is counted twice on one side. Once it is set, the grid at page width offers two more views after Total: the second field's total, and Difference, the first total less the second in each cell. An issue carrying only one of the two counts as zero for the other: time logged with no estimate adds to the difference in full, and an estimate with nothing logged takes from it in full. The figures add up to their margins, and a figure opens the issues carrying either field where Jira's search can name both. In a dashboard column the views stay as they were, and the chart draws the first total only. Crosstab Change with the same settings shows the step in the difference.

Set the options

The form draws a line and says so. The choices above it are what a grid is made of. Everything below it is optional, and the grid draws without it: the field to add up and the settings after it.

Leave out work that is finished. Finished issues are excluded from the read. Know this before you turn it on: Jira answers the count of what it skipped with a figure it calls approximate, and the grid says so. It is the only number in this gadget not counted from the issues themselves. Why.

Also count: Epics · Sub-tasks. Both are off by default. An epic carrying the sum of its children, counted beside the children, is the same work counted twice. Time logged is the exception, because a worklog on a sub-task is the only record of that work. Choose Time Spent as the metric and the form ticks Sub-tasks, with a line saying it did. The Σ fields already add up their sub-tasks, so choosing one does not tick the box. Clear the box to leave sub-tasks out.

Start from another Crosstab gadget on this dashboard

• Open the settingswhere there is already a Crosstab on the dashboard, the others are listed. Each is named by what it adds up, by what, and over which issues.
• Pick onechoose the gadget to start from.
• Use or copypress Use these or Copy them.

The two buttons are two different promises:

• Use these links this gadget to the one you picked. It draws with that gadget's settings, and when they change, this one changes with it. The gadget says above its figures which one it follows.
• Copy them fills the form with that gadget's settings as they are now. After you press Save they are this gadget's own, and the two change separately.

A gadget that follows another can Stop following from its settings. It keeps the settings it has at that moment as its own. If the gadget it follows is removed, it says so and asks you to choose again rather than drawing nothing.

This is how a Crosstab Change and a Crosstab Chart are usually set up: beside the grid they are about, following it. With the same settings the three read Jira once between them.

Read the grid

Switch views at the top of the grid. There are nine. In a dashboard column it offers four: Total, Issues, No value and % of row. At page width it offers all nine:

The two shares are different questions, and a crosstab answers whichever one it is asked. What share of this sprint was bugs is read down a column. What share of the bugs was this sprint is read across a row. Neither is the default reading of a grid whose margins are both headed Total. So the sentence under the table says which one is on screen and which margin adds to a hundred. How the shares are rounded.

Average divides by what carried a value, not by what is in the cell, and says so under the table. A margin is no exception: it divides its own sum by its own such issues rather than averaging the cells it covers. Where those cells rest on different numbers of them, the two need not be the same figure.

Smallest and Largest say what a total hides. Forty points in a cell is one story of forty or forty stories of one. The largest is the figure that tells them apart. Both pick from the issues that carried a figure, so a cell where none did is empty rather than 0. A margin is the smallest or the largest of everything in its row or column. It is always one of the figures beside it.

Median is the middle figure. A few large issues do not drag it the way they drag an average. Nine stories of one point and one of forty average 4.9 and have a median of 1. It needs every value at once, and this app keeps none. So it is offered on the live grid only. It is not offered on a kept or published grid, or while comparing. Nor is it offered on a grid read in more than one sitting, or on one that takes part of its old finished work from the totals held for it. A margin is the middle of every issue in its row or column, so it need not match any cell beside it.

No value is the one to look at before quoting any of the others. A total drawn over a board where a third of the issues are unestimated is not wrong. It is not the whole board either, and this view is where that shows. Mark what is missing points at the same thing on the totals view. It marks each figure that left out 20% or more of its issues because they carry nothing.

Open a figure

A figure opens the issues behind it. Total, Average, Smallest, Largest, Median and the two shares open only the issues in their cell that carry a value. That is as many as the smaller number beside a total, because an issue with no value is in none of those figures. Issues opens every issue in the cell, and No value the ones with none. Zero is a value: an issue estimated at 0 is in the list. A figure over issues none of which carries a value opens nothing, and says so.

Where the grid leaves issue types out - epics and sub-tasks, unless you count them - a figure's search ends with issuetype not in (...) and the ids of those types. That keeps the list to the issues the figure counts, and the line under the grid names the types.

The exception is a metric a search cannot name: a time between two dates, time logged in a month, or a field Jira cannot search on. There a figure opens every issue in its cell. No value does not open at all, because its search would have to name the metric.

See how it was read

Under the grid, How this grid was read, and what it leaves out prints the whole provenance. It says where the issues came from, how many were read, and what was skipped and why. It is the paragraph to paste into a meeting alongside the number.

Quick answers

Draw a chart

Crosstab Chart is the gadget for it. Its settings offer four drawings: stacked bars, bars side by side, each row as shares of a hundred, and a line for each row, up to the six largest. It draws the count of issues or the sum of the field, whichever the settings add up, with the figures in a table under it.

The line is offered only where the columns run in time: a date at any grain, or sprints. It runs earliest first. A chart saved as a line can lose that, because its settings or the gadget it follows changed. It then draws stacked bars and says why. It keeps the line for when the columns run in time again.

The bars show only the work still open. A column that is a status in Jira's done category, Done or Canceled say, is finished work. It is left off the bars, and the sentence under them names it. Where finished work is all there is to draw, it is drawn.

Up to seven columns are drawn one by one. Past seven, the six columns with the most in them are drawn one by one, and the rest are drawn together. That is one segment at the end of each stacked bar, or one bar at the end of each group when the bars stand side by side.

The table under the chart holds what the chart draws. A column left off or drawn together is left off or together there too. So are the rows past the ten largest it draws as bars, or the six largest it draws as lines. Nothing is dropped from the grid itself: every column and row is in the grid Crosstab draws.

Switch to a chart

At page width the grid has a chart of its own as well. Chart draws the grid instead of tabulating it, in one press and with nothing to configure. It is the grid that is on screen: the same view, the same sort, the same limit on how many rows and columns are drawn. It draws one bar per row and one colour per column.

The parts of a bar are laid end to end where they add up, which is every view but one. An average of four in one cell and six in the next is not ten of anything. So on Average the parts stand side by side instead.

Table brings the figures back. There is no figure on the chart to read, copy or search, because a canvas holds no text at all. That is why the two are a switch rather than a chart drawn under a table.

Show the last sprints

Crosstab Sprints draws two bars for each sprint, oldest at the top. One is what went in: there at the start, or added after it. The other is what came of it: closed by the end, or not. It draws the last three, six or ten finished sprints, as the settings say, and the one running, counted up to now.

Crosstab Sprints and the grid can give different figures for the same sprint. Work carried from one sprint into the next is counted in Crosstab Sprints under each sprint it was in. The grid's sprint axis counts it once, under the sprint it is in now.

It is worked out of each issue's own history when the dashboard loads. Within five minutes, a reload by the same person is answered with the sprints already read, as a grid is. Nothing else is kept.

The start is the sprint's start date. Closed is a status in Jira's Done category when the sprint ended. The figures use each issue's estimate as it is today. The gadget says so where an estimate changed after its sprint began. Jira can hand back only part of a busy issue's history. Where the missing part decides the answer, that issue is drawn as not in the record, and counted in a sentence. A filter reaching several boards draws the sprints of the board most of its work is on, and says so.

Its read is its own. It reads the history of every issue in the filter that has been in a sprint. No other gadget shares that read or pays for it.

In a dashboard column

A gadget gets the width its dashboard's layout gives it. In a two- or three-column layout that is 346 pixels. That is where this product lives, not an edge case. So what it does there is deliberate, and worth knowing before you choose an axis.

The table scrolls sideways, and what is off the screen is counted. Eleven statuses across the top want about 900 pixels against a window a little over 300. So most of them are out of view. The gadget says how many, as a number under the table. The row labels and the Total column stay put while the rest of it moves.

It offers the axis that would fit. Where the table is wider than the window and the grid has fewer rows than columns, it offers the swap. The rows are the columns the other arrangement would draw, and it says how many. Where the rows are not fewer and the columns are statuses, it offers the coarser field instead. It says so in these words: "Status Category, in place of Status, draws the same work in three columns that fit." It offers one or the other and never both. Two pieces of advice about one wall spend two lines saying what one says. A board with ten statuses across the top and four issue types down the side gets the swap. That is why the swap is the offer most readers meet.

A long label gets a second line before it is cut. Labels on both axes are capped at twelve characters, because the cap is what buys the readable window back. A label past it wraps, so Ready for Development and Ready for Grooming stay two rows a reader can tell apart. A label too long for both lines is cut after the second. Hold the pointer over it to see the whole of it. You pay in height, which scrolls, rather than in width, which does not.

The shading ranks the whole grid rather than the part on screen. That includes the cells this window is not showing on either side of it, and it leaves the totals out. So the deepest fill you can see need not be the deepest there is. The gadget says so where it is true rather than leaving you to infer it.

Two numbers in one cell need room. On the totals view a figure carries a second, greyer one: how many issues it is a sum of. That appears only where the gadget is wide enough for both, which is 392 pixels and up. A narrow column does not draw it. Nothing is lost by that. The same count is what a screen reader reads out on every figure, and the Issues view is a whole grid of them.

Keep a grid

Keep this stores the figures as they are now. A number quoted in a meeting can then be defended six months later, when the issues behind it have moved.

What is stored is this app's own totals and the choices that produced them. It is not a copy of your issues: no issue keys, and no field values beyond the labels already drawn on the axes. On the Parent axis that label is the parent's own summary, usually an epic's. It is the one label on the grid that is ticket text, and it goes into your own site's app storage and does not leave it. What is stored, in full.

The panel says whether the grid in front of you is the one already kept, by comparing the total and the issue count. So a press can be spent where the board has moved. That matters because a history holds fifty grids and no more. How far back it reaches is decided by how often a grid is kept. The moment a press records is the moment you pressed it. The close of a sprint or a week is what Keep automatically, below, is for.

A history belongs to the settings that made it, not to the gadget. Changing what the grid is of starts a history of its own. That means either axis, the metric, the filter, or either of the two boxes under Also count. The grids kept under the old settings stay where they are. At page width they are in their own group in the list beside Keep this.

You can hold ten of those histories across all your gadgets. Once you hold ten, the line beside Keep this names the history a keep under new settings would remove, and when a grid was last kept there. Pressing Keep this then asks first: Remove and keep this, or Cancel. Nothing else removes a history to make room. Deleting every grid in a history frees its place. The fifty and the ten are one limit rather than two promises. The form says both figures where there is something kept for them to be about. On a dashboard, the count of grids kept beside Keep this opens that list at page width. Beside it, Changes since opens the grid at page width, each figure beside how much it has moved since your newest kept grid. The button carries that grid's date.

Keep it automatically

Keep automatically, beside Keep this, presses it for you. It keeps every week on the day you choose, on the 1st of each month, or whenever a sprint closes. Each is kept then, or as soon after as Jira allows. It is yours in the same way. It reads with your own Jira permissions while you are not looking. It keeps into your own history, beside the grids you keep by hand.

On a sprint's close it keeps only that sprint's issues from this gadget. That is the gadget's own filter or search, with openSprints() narrowed to the sprint that closed and sprint = that sprint added. It names the grid after the sprint, so it can be told apart from the full grids in the same history. A gadget with none of that sprint's issues keeps nothing.

Days are counted in the time zone of your Jira profile: Monday is your Monday, and the 1st is your 1st. A week or a month whose run was missed is kept the day after. It keeps nothing where the grid is empty. It also keeps nothing where a weekly grid read whole holds under half the issues of the last one kept, in case the read went wrong. A month is kept however small it is: one month's work can be half the last one's, and a skipped month is a missing report. Nor does it keep anything where its settings have no history yet and you already hold ten: it removes none of yours to make room. It says which of these happened next to the control. A read cut short is kept, marked so, as Keep this keeps one. Nobody waits on it, so it is given a longer clock than a read in the gadget and a ceiling of five thousand issues.

Jira meters every installation of this app out of one hourly allowance. So the schedules on a site spend at most a tenth of it in any hour. A grid that does not fit waits for the next hour. When Jira says the allowance is running low or refuses a read, every schedule stands back until it has room again. A grid put off this way says it is waiting rather than that it failed. It is never kept half read. It is kept as soon as there is room: a week the same week, a sprint the same sprint. It stops if Jira will no longer let the app read as you, and says that too. How a schedule reads.

Only the gadget's saved settings are kept this way. A site runs at most twenty such schedules, and one person at most three of them. Nothing kept automatically is ever published. A gadget that follows another offers no Keep automatically. Its schedule would be the one on the gadget it follows, so it is switched on there. Where you run others under different settings, the control says how many and offers to stop them.

When you change a gadget's settings, Keep automatically moves to them the next time you open that gadget, on the same schedule; until then it keeps under the earlier settings. Grids already kept under the earlier settings stay, listed under Kept under other settings.

See what moved

Crosstab Change is where a kept grid is compared with today's on a dashboard. It opens on the newest grid it can measure against, and Since chooses an older one. It says how much the total has moved since then, and which five cells moved most. Show all lists the rest. Its own Keep this keeps today's grid, and the next changes are measured from it. Copy puts the list on the clipboard.

At page width a kept grid can be opened as it was, or compared against today's with the difference drawn in place.

Show one cell over time

Show one cell over time, at page width, appears once two grids have been kept. It answers the other question: not what one figure was on one day, but what it has been doing. Choose a row and a column, and say how far back to go. It reads that one cell out of the last several kept grids, twelve by default and up to fifty. It draws them oldest first, with what each one moved.

Once fifty are kept it can also go as far back as it goes, up to two hundred moments. Those older than the fifty grids are listed by their date with no figure, because only their totals were kept, not their cells. The last column on offer is the total at the end of the row. Where the grid on screen is the one read from Jira just now, the line ends on it, as Today.

It reads whole grids out of storage to answer with a handful of numbers. So it happens when you press it rather than every time the dashboard loads. Changing the view afterwards costs nothing: all five are worked out from the same read.

Show the grand total over time

Show the grand total over time, at page width too, appears once two grids have been kept with the same filter and metric, whatever their rows and columns. So it also runs through what moving an axis leaves behind. A cell of one history is not a cell of the other. The grand total counts each issue once, whatever rows and columns it lands in, so it runs through both. It draws the last twelve kept grids, oldest first, each saying which rows and columns it was kept with.

It follows the total, the issue count, the average, the smallest or the largest, whichever is on screen. Under a share it follows the total, since a share of the grand total is always all of it.

Publish a grid

A kept grid is yours: a colleague opening the same gadget sees their own and never yours. Publish this grid is the one way to hand a grid to them. It leaves the grid on that gadget for whoever opens it, under your name and the date it was read. They choose whether to show it in place of their own read.

Publishing is off until a Jira administrator turns it on. They do that on the Crosstab page under Apps in Jira's administration. Until then the gadget shows no Publish this grid button. It says beside Keep this that publishing is off and who turns it on.

The figures published are not the ones on your screen. The press reads your filter from Jira again, as you, and publishes that. If that read stops before the end of the filter, or Jira does not answer it, nothing is published and the gadget says why. A published grid always counts every issue in the filter.

What they see is your view of Jira, not theirs. If your permissions show you issues theirs do not, the published figures count those issues. That is why the gadget draws the grid under a banner naming whose view it is. It also asks before you publish, except when your own published grid is the one showing on that gadget.

There is one published grid per gadget. Publishing again replaces yours. A colleague's can be replaced or taken down only by them. Take mine down removes yours, and is offered only under the settings it was published under.

Turned off again on that page, the button is gone once more. Grids already published are hidden until it is turned back on, not deleted.

A Crosstab Change that follows the gadget a grid was published on can measure against that grid too. It names who published it and when. It says that part of a step can be a difference in what the two of you can see, not a change in the work.

Export the table

Under the table, beside Open at page width, are two ways out:

• Copy puts the table on the clipboard, ready to paste into a spreadsheet.
• Download opens a list of three. CSV and Excel write a file. Picture writes a PNG of the table as it is drawn. It is the one way out that goes into a slide or a chat message rather than into a spreadsheet.

The Excel workbook carries the No value view as its own sheet, where there is one to carry. Two boards get no such sheet. One is a board on which every issue holds a figure, because a tab of zeros is a tab a reader opens once. The other is the No value view itself, where the first sheet already is that table.

Every export carries the provenance paragraph the screen shows. The workbook carries it on its About sheet. That includes a warning across the top when the read was cut short: in capitals in the two text exports, and as a word in bold in the workbook.

Each says as much of it as it can. The two text exports drop the sentences about a fill they have not got. The picture keeps them because it has the fill. The workbook adds the ones about its own sheets. The picture holds the table it is a picture of, and says so where the screen is showing more than one. A comparison and a series travel in the two files rather than in the image.

A grid with Against set adds a Second field sheet, the second field's total, and a Difference sheet. Each figure on Difference is a formula: the first total less the cell on Second field, so it can be checked and changed in the spreadsheet. The first total is the Grid sheet when the grid shows Total; otherwise a Total sheet is added for the formulas to point at.

Crosstab
Story point estimate by Status and Issue Type, in All work
From the saved filter “All work” (id 10001)
The search that was run: filter = 10001
Read 4789 issues
Read at Nov 2, 2026, 10:31 AM (UTC)
Read with the permissions of whoever exported this. Another reader may see different totals.
1737 issues carry no Story point estimate, and add nothing to the total.
6 epics and 429 sub-tasks were not counted, with 20 in Story point estimate between them.
The corner total covers only the 2617 issues that carry Story point estimate. A grid of another field covers other issues, so subtracting one of these totals from the other does not give the difference between them.

Point a formula at it

Paste the table into a template and you are pointing a formula at a column. You need that column to still be that column after the next release. It will be. What is promised:

• The table is a heading row, one row per group down the side, and one margin row last.
• Every row of it is exactly two cells wider than the grid: the heading on the left, the margin on the right. The corner is the last cell of the last row.
• The columns run in the order the grid draws them, left to right. The rows run in the order it draws them, top to bottom.
• The clipboard, the CSV and the Excel workbook all carry that same table. It is tabs for the clipboard, commas for the CSV and cells for the workbook. Nothing else about the shape of the table differs.
• The workbook holds each figure as a number rather than as text, under a number format that writes it the way the screen did. So a column of them adds up, and still reads the way you saw it.

What does differ is this. The workbook writes a field Jira stores in seconds in the unit this site asks for. Where the site writes 2w 1d 3h, the sheet is in hours instead and says so above the table: a cell holds a number, and that form is not one. The two text exports write the stored seconds and say so above the table. The workbook also puts a comparison's three tables on sheets of their own, where the other two run them down one file. And it is found by a different rule, below.

The picture is not in this list, because nothing can read a picture back. It carries the same figures under the same headings. It is for looking at rather than for pointing a formula at.

What is not promised is which row the table starts on. The lines above it say as much as they have to and no more. A read that was cut short says so, a metric with a unit names it, and a file whose headings needed an apostrophe explains why. Pinning that to a fixed row would mean the file saying less than it knows.

Find the table instead by its first line. It is the first line that begins with the delimiter: a tab for the clipboard, a comma for the CSV. No line above the table can begin with one. Everything above it is a single field, and a field holding the delimiter is quoted.

Where a comparison is on, the file holds three tables, each under a heading of its own. So there are three such lines, and the first of them begins the first table. They are not all the same shape. The grid the comparison is measured against is drawn on its own axes. So it can hold groups this one no longer has, and its columns can run in a different order. Read each table's own first line for its columns rather than carrying the first table's over the other two.

The workbook puts each of the three on a sheet of its own and has no delimiter. There, on every sheet carrying a table, the table is the first row with a cell in the second column.

All of the above is held by a test of its own. It exists so that a change to the grid cannot quietly change your template.

Save a setup

A setup is a named set of the choices. Save it once and start from it again on the next gadget.

Setups are visible to the whole installation rather than to you alone. The form says so where the search is typed: a JQL line can name a person, and a line you write is a line your colleagues can read. Anybody can start from a setup. Only whoever saved it can save over it or forget it. Somebody else wanting a different version saves it under a name of their own. One person may have ten setups in the library. Saving an eleventh removes your oldest, and the save says which.

A setup carries the field under Against along with the metric. Applied where its metric cannot be set against that field, the form leaves it out, the way it does when the metric moves.

Keep gadgets in step

Four teams on one dashboard is four gadgets that differ in the filter and agree in everything else. Build each of them from the same setup, and each one remembers which setup it came from.

Save that setup again later, with a different metric or another axis. The next time you open any of those gadgets' settings, the form says which choices have moved and offers to take them. Taking the change leaves that gadget's own filter or search alone. So four grids of four teams stay four teams.

Against is not one of the choices the form offers to take. A gadget keeps its own until you change it there, or start from the setup again.

It is a click in each gadget rather than a walk through each form. Nothing changes on the dashboard until you press Save. A gadget whose settings you never open goes on drawing what it was configured to draw. Nothing about this app changes a grid behind you.

Know its limits

No axis can be a person. Not assignee, not reporter, not creator, not any user field on the site. A total broken down by a person is a metric about that person, and that is not what this gadget is for. The rule is checked against the schema of every field your site returns, rather than against a list of field names.

No external host. The gadget reads nothing but your own site, so there is nothing to add to an allowlist. Nothing runs on a schedule that nobody asked for either: the one read made while nobody is looking is Keep automatically. A person switches it on for themselves, and it reads as them and keeps into their own history.

Everything else is read only while somebody is looking at the gadget or pressing something on it:

• when the dashboard loads or Refresh is chosen in the gadget's menu;
• while its settings are open;
• when its grid is opened at page width;
• when someone presses Read again beside the caption, Finish this read or Try again.

The words before Read again say how old the figures on screen are.

Within five minutes of a read, a reload or Read again is answered with the grid already read rather than from Jira. That is a read that finished, or one that stopped at the ceiling of twenty thousand issues. Every read is spent from one hourly allowance the app shares across every site it is installed on. The press says when it will next read.

No deep configuration. There are four choices and three settings. Four more are drawn only where they can do anything:

• the grain of a date axis;
• the other fields to read an estimate from;
• how to write a length of time, on a site that writes one out in full;
• what to call a search of your own.

Crosstab Chart adds one, which drawing. Something new is a gadget of its own rather than another setting on this one. That is not a roadmap gap. It is what keeps the app supportable by one person.

No language but English. Every word the gadget writes is in English, whatever language your site is set to. That covers the captions, the sentences under a grid, the refusals and the headings in an exported file. It is not read from your site's setting and then approximated. There is one catalogue, and the gadget does not pretend to have another.

What is in your language already is everything the gadget did not write. Axis labels are your statuses, your issue types, your components, your labels and your field names, exactly as they are spelt in Jira. So a grid on a German site reads as German data under English captions. Each part is spelt by whoever owns it. The headings on a date axis are the gadget's own words, so they are English: Jan 2026, Week 38, 2026, Q3 2026.

Dates that are not axis labels follow your browser instead, in four places. They are the banner over a kept grid, the list in the picker, and the name and the Read at line of an exported file. A file you send on is therefore written in your own locale and read in somebody else's. That is why the date inside it and the date in its name are taken from the same clock.

When a read fails

Every refusal says which of the two it was, the filter or the issues, and what would fix it. That is somebody to ask for a share, an administrator to grant a scope, or simply a wait when Jira asks the gadget to slow down. A read that ran out of time draws what it got. It marks the totals partial rather than presenting them as complete.

What each one says about trying again depends on why it failed:

• Jira did not answer, or asked the gadget to slow down. The gadget tries again the next time the dashboard loads. Its own menu carries Refresh for trying sooner. Where Jira named how long to wait, the refusal says so, and a reload before then meets the same answer.
• The refusal is about permission, or something Jira cannot find. It says that waiting will not change it, and what will instead: whoever administers the site, or the gadget's settings.
• A read did not finish, or the gadget could not reach Jira at all. Both carry Try again, which asks again without the dashboard being loaded a second time.

What it spends of Jira's allowance

Jira limits what this app reads to 65,000 points an hour, refilled at the top of every UTC hour. The allowance is the app's, not your site's. Every site that has the app installed spends from it. When it runs out, every gadget on every site stops reading until the hour turns.

Grids kept automatically on your site spend at most 6,500 points in any hour, a tenth. Gadgets people open on your site spend at most 13,000 points in any hour, a fifth, counted apart from the schedules. The limit is the app's own, so that no few sites can use up the hour every other site shares. It is the same for a site of ten people and of a thousand: about four first opens of a 3,000-issue grid that adds up a field.

Once your site has spent it, a gadget that would read Jira says so, and when it lifts: the start of the next UTC hour, in your own time. A read under way stops at its next page and says the same. A press of Publish this grid reads the filter again, so it counts against the same share. A grid or the sprints held for five minutes, and a kept grid, ask Jira nothing and open as before. A published grid asks only the name of whoever published it. It opens without the name once the share is spent.

Within that, what bounds one gadget is the read. One load reads about 3,100 issues on an ordinary site. Finish this read carries on from there up to 20,000 for one grid - about 20,200 points, more than your site's gadgets may spend in one hour, so a read that size finishes in the next hour.

So the size of the filter decides the cost. A large filter adding up a field is the expensive gadget. A Total that counts issues is cheap however large the board is. So is a grid that counts them on the axes listed under "Counted cell by cell" below, once the person opening it has kept that grid.

What one open costs. A search costs a point, plus one for every issue it returns. A count of the issues a search holds costs two points. The field list, a saved filter and the reader's time zone cost a point each. Where the hourly allowance and these prices come from is on the method page.

Three cases change the cost.

• After five minutes, unchanged costs two counts rather than a read. That holds only where the filter names no function or relative date, such as openSprints() or -1w. A filter that does is read again in full.
• Counted cell by cell applies when a grid counts issues on two axes Jira can list, and its counts number fewer than a third of the issues. There is one count for each cell, each row and column total and the whole. The axes Jira can list are status, status category, issue type, priority, resolution, board column, or one of Jira's own dates by week, month and so on. Priorities and board columns are Jira's own lists; every other axis takes its values from the last grid the person opening it kept of the same settings. So do the issue types of the epics and sub-tasks the grid leaves out, where the filter holds any. Until that person has kept one, a grid that needs any of those is read in full. It costs two points for each cell, each row and column total and the whole, plus six to size the filter with the default settings. A grid that counts by assignee, label, epic or sprint reads every issue.
• Old finished work on a board with 500 or more finished issues resolved before this month is read once and then kept as totals. They are kept for each person and each set of settings. Later opens read open and recent work. So a board with years of finished work costs roughly what its open and recent work costs.

Crosstab Sprints reads every issue in the filter that has been in a sprint, with its history. It does that on the first load in five minutes for each person, and the history is not charged. Past the five minutes it reads them again whatever Jira's counts would say, because a running sprint is counted up to now. Crosstab Chart and Crosstab Change read their grid the way Crosstab does and cost what it costs. A Total set to follow a grid on the same dashboard (Use these) shares that grid's read for the same person. A Total with settings of its own reads for itself.

When the allowance runs out.

• Refused before reading: no figures, and a line saying Jira asked the site to slow down and, where Jira said, how long to wait.
• Refused partway: the issues read so far, under a banner saying the totals are incomplete. This grid is not held; the next load reads again.
• Kept grids: wait for the next UTC hour, or longer where Jira asked, and say they are waiting for Jira's hourly allowance rather than that they failed.

The message names your site, but the allowance is the whole app's. It can run out because of use on other sites.

Working it out for your site.

points an hour ≈ first opens in the hour × (issues in the filter + 1 per 100 issues)

A first open is one person opening a gadget with one set of settings for the first time in five minutes. The five minutes are held for each person, not for each gadget. Ten people opening the same dashboard are ten reads, and one person opening it ten times in five minutes is one. People who are not signed in, on a publicly shared dashboard, are never held, so each of their loads is a read. The formula is for a grid that adds up a field; the three cases above cost less.

Leave out work that is finished makes a read smaller where old work would otherwise be read.

When the subscription ends

A trial that runs out, or a subscription an administrator lets lapse, stops the gadget drawing figures. It says so on the dashboard rather than going blank.

Nothing kept is deleted. Every kept grid and every saved setup is still in the site's storage. A subscription started again draws them exactly as they were.

The app refuses nothing that takes something away. These go on working without one: deleting a kept grid or a saved setup, taking your own published grid down with Take mine down, and switching Keep automatically off. So does the settings form, so a reader can see what a gadget was configured to draw. Holding somebody's own data behind a subscription is not a lever this product is willing to pull.

On the dashboard, a Crosstab on a site without a subscription shows the sentence saying so. Under it is what is yours there to remove. That is your grids kept under its settings, each with a way to delete it, and Take mine down where the grid published on it is yours. Keep automatically is there too, with only Off to choose. Nothing in it keeps, publishes or opens a grid.

Remove it

Remove the gadget from the dashboard the way you would any other. Kept grids and saved setups live in the site's app storage rather than in the gadget. So they survive a removed gadget. When an administrator uninstalls the app, Atlassian keeps its storage, and these with it, for 28 days, then deletes it. After uninstalling says what can be restored in those days.