Setting up Outlier

A dashboard gadget that reads one board and has something to say about it on a good half of mornings, if the board runs two-week sprints — on a long-running backlog it is quiet for weeks at a time. This page is how to put it somewhere and what to expect for the first fortnight. What it measures is a separate page — see Method, which is published in full for the same reason this one is short.

Adding it#

The app comes from the Atlassian Marketplace, and installing it is a Jira administrator's job, done once for the site. The four steps below are what anybody does afterwards, and they need no permission at all.

1. Open a Jira dashboard, or create one. Dashboards → Create dashboard.
2. Add gadget, then find Outlier.
3. Pick a board. The list is the boards you can see, and the picker names the project each one belongs to, because two boards on a site are often called the same thing.
4. Save.

That is the whole of the required setup. Everything below is optional and can be changed later without losing anything.

A board needs a saved filter behind it. Almost all do; a board without one cannot be read at all, and the form says so when you pick it rather than letting you save something that will never work.

What happens on the first day#

Outlier reads the board's history as soon as it is configured — not from the day you installed it. That walk takes a few minutes on a small board and up to an hour on a large one, and the card says reading this board's history while it runs, with a count.

When it finishes, most columns have a norm and the card starts working. A column that has passed fewer than fifteen tickets in the last year has no norm of its own; where its role is clear — to do, in progress, review, done — it borrows the norm of the columns sharing that role, and the card marks it as borrowed. Where the role is not clear there is nothing to borrow from, and the card says so rather than pretending.

A column can also have plenty of finished work and still get no norm, when the wait in it has changed: the older stays no longer describe it and not enough has finished since. The card says which of the two is happening and counts what is missing, so a bar that reads 12 of the 15 recent stays a new norm needs is a bar that moves.

You do not have to wait a sprint. That is deliberate: a product that needed four months of watching before it was useful would need to be free.

What it costs the Jira it is pointed at#

The person who installs this is the one who answers for it, so here is what it spends. Counted by running the shipped code against a stub of the two Jira search APIs, rather than by reading it and reasoning.

The first walk: one request per fifty tickets read, plus one status lookup per two hundred. A board of a thousand tickets is about twenty-five requests, spread over five wake-ups rather than made at once; five thousand is about a hundred and twenty-five over twenty-five wake-ups. It happens once.

After that the unit is a pass, not an hour. The app wakes every hour but only reads a board when that board is due: often in the morning it is read in, more slowly through the working day, rarely at night. That comes to about fifty-three passes a week, and a pass that is not due asks Jira for nothing at all.

A pass that does read costs one request for the site's status dictionary, plus three per board — the board's configuration, the saved filter behind it, and one search — plus one more search per fifty tickets that actually moved since the last pass. One watched board is four requests a pass and about thirty a day; ten boards on the same site are thirty-one a pass, because the dictionary is read once for all of them.

Three things that follow. The collection reads only what changed, so the bill tracks how much the board moves rather than how large it is. A second gadget on the same board is not a second collection: the board is walked once and the gadgets are views of it. And the cost per board falls as boards are added, because what they share is read once.

What this does not tell you is latency, or where your site's own rate limits sit — those belong to your instance and your plan, and we would be guessing. What it does say is the order of magnitude: tens of requests an hour, not thousands.

What the first weeks add#

There is no watching period. The board's history is read at setup, the norms come from that history, and the first morning's card is the whole product: the findings, the columns behind them, and the footer saying how much of the board was looked at. The columns still short of a norm are the exception, and the card names them and counts what they are missing.

What time adds is the card's own record — a row of squares showing which of the last ten mornings it had something to raise. Until that record exists, the card says what it would have said over the board's last quarter — on a morning with nothing new to raise, where there is room to read it — reconstructed from the same history and measured by the norms in use now. It is labelled that way wherever it appears: there was no card on those mornings, and the line never pretends otherwise. Once ten mornings of squares can make the same point from evidence, the reconstruction stops being shown.

On a board where no column has a norm yet there is nothing to reconstruct, and the card says that rather than reporting a quiet quarter it cannot see.

Reading the card#

Three findings at most, ordered by how far past this board's own normal they are. Each one carries the numbers it was derived from — how many tickets, how long, and how many finished stays the norm came from — so any of them can be checked against the board itself.

Under them is a footer saying how much was looked at, how much is in flight, and how many columns are being watched. That line is the point of the product: it is what makes a quiet morning a result rather than an absence.

"How this was counted" opens what the morning was measured against: how much of the board was looked at, how much of it was standing still, and how far back the stays behind the norms reach. The sample each norm was built from is printed where it is used — in the sentence under the finding itself.

Copying it into a thread#

Copy puts the card into your clipboard as text for Slack, Teams or a Jira comment. with evidence does the same with the numbers behind each finding.

The card is built to travel to where the standup already happens rather than to gather people around a dashboard. The text is assembled from the same numbers and the same sentences as the card, so the two cannot say different things in front of the team. It differs where a thread is not a card, and each difference is deliberate: where two findings would ask the same question word for word, the card prints it once — three in a row stops being a question and becomes a template — while the text keeps it on every line, because a line pasted into a thread is read on its own. The date is written the way a thread writes dates, the footer is spelled out rather than folded away, and Copy leaves out the line of evidence under each finding, which is what with evidence puts back.

Sending it without opening a dashboard#

Copy works, and it needs somebody to press it. If the standup happens at a fixed time in a channel, a rule can fetch the same morning and put it there without anybody visiting the board.

Outlier does not deliver it. It answers when your own rule asks — your trigger, your schedule, your channel, your credentials — and nothing it reads leaves your Atlassian site except through the step you write. That is the whole reason it works this way: an app that posted to your Slack itself would need an address outside Atlassian, and this one has none.

In Automation, build a rule with the trigger you want — Scheduled for a fixed time on working days — and add the step Read this morning's questions. It asks for one thing, and the form below is that step drawn from the same component the rule editor uses — a sample rather than something to fill in here, and the Next it mentions belongs to the rule editor around it:

The card already knows the board, the saved filter and the labels, so there is nothing else to fill in. Where one board carries two Outlier gadgets they are told apart by what each is narrowed to, or by a quick filter, or by the day it was added.

What happens when the read fails. The step answers the rule with an error rather than with an empty morning, so the rule stops and Jira writes it in that rule's audit log — the card never posts "something went wrong" into your channel, because the person who can fix it is not reading the channel.

The cost of that is worth saying out loud: a channel that goes quiet looks the same whether the board was calm or the collection broke. Three things tell them apart. The card on the dashboard says which of its states it is in, with the age of the last read on it. The step hands back said, so a rule that posts only when there was something to say can be written to say so. And it hands back state, which is the one to branch on if you want to be told when something is wrong.

Then add whatever carries it. The step offers four values to use in the one that follows:

Take them from the smart-value picker rather than typing them: Automation composes that name from the app's own manifest.

Being told when it stops#

We cannot tell you. There is no address outside Atlassian in this app and no permission to write anything into Jira, which is the same architecture that keeps your board's data where it is — and it means there is no channel from us to you, by construction rather than by omission.

What there is instead is a value your own rule can act on. said cannot do it: a quiet morning and a broken collection both answer no, which is the whole difficulty. state names them apart.

So a second rule, scheduled weekly, with one condition:

If {{fetchedOutlierMorning.state}} equals failed or stale, send a message to whoever administers Jira here, with {{fetchedOutlierMorning.text}} in it.

That message is the app saying what is wrong, in your words, to the person who can fix it, on a schedule you chose. It is the same arrangement as delivery, for the same reason: your rule asks, and nothing leaves your site to make it happen.

Worth doing at setup rather than after the first silence, because the failure this guards against is one that looks exactly like nothing happening.

Why there are two forms of the text. Automation substitutes a value exactly as it is, and the morning has line breaks in it. Pasted into a message field that is what you want. Pasted between the quotes of a hand-written JSON body — which is how an incoming webhook is usually addressed — raw line breaks make the body invalid, and the endpoint answers with an error that says nothing about why. textJson is the same morning with those escaped, so {"text": "{{fetchedOutlierMorning.textJson}}"} is valid JSON.

A quiet morning still says something, which is the point of the product and worth deciding about here: the text is never empty. If you would rather the channel stayed silent on the mornings with nothing on them, put a condition on said before the step that posts.

If the step is pointed at a gadget that has been repointed or removed, the rule stops and says so in its audit log rather than posting the problem into the channel. That is deliberate: the person who can fix it is not reading the channel.

The step needs a subscription, and stops rather than degrades without one. Where a site's subscription has lapsed the platform does not run the step at all, and the rule records the reason in its audit log — again rather than in the channel. The card says the same thing in its own words to whoever opens it, which is the difference worth knowing about: a rule that posts at seven in the morning is noticed by its silence, and silence takes longer to notice than a sentence.

Asking why#

Where your site has Rovo, a third control appears: Ask Rovo why. It opens your own Rovo with the card and one question already written — what in the comments or the linked work explains these waits.

The button opens Rovo; it does not run it. Nothing is spent by the card being drawn, and nothing is spent by the button being there — a press opens your own Rovo with the question already typed, and whatever happens after that is metered by Rovo the way any other conversation in it is. Outlier neither sees the answer nor pays for it.

Whether the control appears at all is not ours to set: it asks Atlassian whether this reader has Rovo, and draws itself only if the answer is yes. On a site without Rovo — or for a person who does not have it — there is no button and nothing changes about the card. There is no switch here to turn it off, because the switch is the one your organisation already has.

Outlier deliberately does not read descriptions, comments or linked work, which is exactly why that question is worth handing to something that does. It runs in your instance, under your permissions, on your credits, and the answer goes to you. If your site has no Rovo, the control is not there and nothing else changes.

The states you will see#

Each of them, drawn rather than described. The two that keep a card keep its buttons, and what those copy carries the banner with it.

Two more things appear over a card rather than instead of one, so they are not in the table: a line counting down the days left in the trial, and, if the gadget cannot reach the app at all, a line saying so and that reloading the dashboard usually fixes it.

Changing what it watches#

Change in the configuration reopens the picker. You can also narrow to labels, choose which columns count as review, set the working week and hours, and frame the card by open sprints.

Narrowing changes what the gadget measures, so it starts the norms again — the form warns you when a change would do that, and the warning goes away if you put the setting back.

Work a board never wants raised#

A column can be a container by design — a parking bay, a queue for work blocked on somebody else — and a card that raises the same true thing every morning teaches its reader to stop looking.

Name a label under Never raise tickets labelled and tickets carrying it stay off the card. Unlike narrowing, this costs the board nothing: the ticket is still read, and still counts towards what a usual wait here looks like, so a team cannot move its own baseline by tidying up. That is also why this row raises no warning about starting the norms again.

A label cannot be both. Narrowing to a label un-parks it.

The working week belongs to the board, not to you. A team that rests on Friday and Saturday says so here, and a reader in another timezone does not change it by opening the dashboard.

Seeing where the cards are#

Installing is site-wide, and after that anybody can put a card on a dashboard without asking. That is deliberate — a card is a view of a board somebody already has access to — and it means the person who installed it has no idea how many exist.

Jira settings → Apps → Outlier lists them: each card, the board it watches, what it is narrowed to, and when it was last read. That last column is the one to read, because a card nothing reads stops being collected for after thirty days and is forgotten after ninety. A rule asking for the morning counts as reading it, so a card delivered into a channel keeps its board collected without anybody opening the dashboard.

Nothing on that page can change a card. To stop one, remove the gadget from its dashboard; the page is there so you can find the one to remove.

Several teams on one board#

Use one gadget per stream, each narrowed to that stream's labels. Mixed streams share a norm, and a norm built from two teams describes neither: on a board carrying three kinds of work at three speeds, the same column's norm came out at 16.5 working days read whole and 5.0 read as one stream.

With one condition. Narrowing costs the gadget the rest of the board's history, so a stream has to finish enough work of its own to be measured — fifteen completed stays in a column, and it says so on the card until it has them. A stream of twenty tickets in a quarter spent six mornings of seven still learning and raised nothing, while the whole board went on speaking. If your stream is that thin, the board's own card is the one to read, and the method page says what that costs.

Removing it#

Reading happens on a schedule rather than when you look: the app wakes on its own timer and collects for the boards it is watching, which is why a card can say its last read is a day old even though you have the dashboard open in front of you. Reading a card is what keeps its board on that list - opening the dashboard, or a rule asking the step for that morning.

Delete the gadget, and stop any rule that reads it. If nothing reads a board for 30 days Outlier stops reading it too, and everything it derived is deleted at 90.

Uninstalling the app deletes what it stored rather than leaving it to Atlassian's retention window.

When something is wrong#

The configuration screen has Copy diagnostic — the state of collection for that board, as text. It carries no ticket data and is the fastest thing to send with a question.

Send it to support@chmut.com.

You will hear back within 48 hours. The mailbox is read between 09:00 and 19:00 in Kyiv, Monday to Friday; Ukrainian public holidays are the exception.

What is known to be broken#

A public issue tracker is a promise this project cannot keep honestly yet. One person answers the mail, and a tracker nobody grooms says less than an empty page does: it fills with duplicates, the dates rot, and a reader cannot tell a dead entry from a live one. This section is what replaces it.

Anything known to be wrong is written here — what it is, when it was found, and what to do about it meanwhile — and it comes off the list when the fix ships, not when it is written. If the list is empty, that is the claim being made, and it is a claim you can hold us to.

Nothing is open as of 16 September 2026.

If what you are seeing is not here, it is not something we know about, and the diagnostic above is the fastest way to change that.