Run health, governance and usage

These pages of the Automation tool show flows that fail, flows that name something Jira no longer has, flows to review for security, what is used in a flow before you delete it, and the month's automation usage. They use the last scan, and some use the audit log.

Run health

Run health lists the flows that fail, that Jira stopped, that mostly do nothing and that have not run. It needs an automation audit log in a scan. See Automation.

Jira's audit log gives each run an end code, and TuneCraft groups them: SUCCESS did its work; NO_ACTIONS_PERFORMED and NO_MATCH did nothing; SOME_ERRORS, FAILURE and ABORTED failed; THROTTLED and LOOP were stopped by Jira for a service limit. CONFIG_CHANGE is an edit of the flow, not a run.

The page has four checks:

Flows are listed worst first, 25 a section, with Show more. Each shows its severity in words, what the audit log measured (runs, steps a month, the days of the last runs), the engine's findings with their saving (estimated), and what to do. Atlassian bills runs that do nothing or fail for the steps they took.

A flow that does not run costs nothing in the audit log, so it is never counted as money: it may be broken, its project archived, or only waiting for a rare event. Only a log exported with "lists every run" ticked proves a flow did not run. A flow started by hand or by an incoming webhook is for information only.

Steps are measured by the audit log; what a fix saves is TuneCraft's estimate. Run health does not change a flow's score. The Overview adds what failed and empty runs can cost only when your site is over what its plan includes, marked estimated.

TuneCraft keeps each flow's counts from the newest audit log, the days of its last runs and the days the logs cover for 400 days: numbers and days only. Someone with the Manage level can choose Remove run health to start again from the next audit log. A confirmation says this cannot be undone.

Tell people

On a flow that fails or that Jira stopped, someone with the Manage level can choose Tell people. TuneCraft can tell the flow's owner and its actor, when Jira says each is an active person (an app is left out), and up to 10 people you pick from Jira. Each gets one Jira work item, created as you in a project you pick. Everyone who can browse that project can read it. The work item says what the audit log shows and what to do, and Jira emails each person. The form shows who was already told and asks for a confirmation.

Broken flows

Broken flows lists the flows of the last scan that name something Jira no longer has, or has differently:

• a field in the trash (with the day Jira deletes it for good), or a name that two fields share;
• a status, work type, priority, resolution, link type, version, component or filter that is gone;
• an archived or trashed project;
• a deactivated owner, actor or account that a step names.

A flow that is turned off is listed for information. A flow that is turned on is high when the break is in a project it runs in or in the account it runs as, and medium otherwise.

TuneCraft compares what each flow names with what Jira has now, once a day (after a scan, at most once a day) in the background, when a Jira admin has turned on the Automation tool's background checks. It reads configuration only, never a work item, and keeps the reason and the id, never a name. Status, work type, version and component names are checked by id only.

Governance

Governance lists the flows to review, from the last scan:

• Credentials in web requests: an Authorization header, a header named for a key, a token or a secret, or a URL that carries one.
• Email outside your domains: email to fixed addresses outside your organisation's domains, and to addresses that smart values give or that TuneCraft cannot read, listed to check. A Jira admin types the domains in Email domains.
• Flows that run as a person rather than as Jira's automation.
• Flows with no owner, or an owner Jira does not show as an active person.
• Flows Jira may have turned off (from the audit log).
• The web requests each flow sends.

It also lists the flows near Jira's service limits: 52 components or more of the 65 a flow may have, with where it could split, and scheduled searches that find 800 work items or more of the 999 a run processes. That count is Jira's approximate count, so it is estimated.

Only counts leave your browser: how many credentials, addresses outside your domains and web requests each flow has, never an address, a host, a header or a value.

Check before you delete

Check before you delete says which flows of the last scan use an object, before you remove or change it here or in Jira's own screens. The object can be a field, an option, a status, a project, a version, a component, a work type, a priority, a resolution, a link type, a label, a filter, a group or a person.

For each flow it shows the owner, whether the flow is turned on, how it uses the object and its steps a month, measured or estimated. Tell the owners creates one Jira work item for each owner.

TuneCraft matches an object by its id and by each name Jira gives it. Two objects of one name, such as a version "1.0" in two projects, both match a flow that names one by name. It never says "no flow uses it" when it cannot know. It says so when there is no scan, the scan is more than 7 days old, the scan kept no record of what its flows use, or the scan may not hold every flow (the site's first scan, fewer than 90% of the flows of the scan before, or entries it could not read). It also lists flows whose references it cannot read, such as a smart value where a name should be. It cannot see what apps and integrations use.

Usage and alerts

Usage keeps each flow's runs and steps a month from every audit log you scan, and the site's steps each day, for 400 days, with a CSV download. A month's counts come from the audit log of every run that covered most of it.

The product a flow bills to comes from its projects' types and is estimated: all service spaces count as Jira Service Management, all discovery spaces as Jira Product Discovery, anything else as Jira.

This month's forecast keeps the month's steps at their pace to its end. For Jira it trusts, in this order: the steps a Jira admin typed from Jira's usage page, the steps a day of the newest audit log of every run when its days end in the last 14 days (both measured), then the last scan's steps a month (estimated). Jira Service Management and Jira Product Discovery have a forecast from the audit log only and are not compared with an allowance, because TuneCraft knows Jira's plan only.

Alerts, set up in TuneCraft settings, create a Jira work item when Jira's forecast reaches 80% and 100% of your allowance, once for each, each month. TuneCraft creates it in the project and work item type a Jira admin picked, mentioning up to 10 active people they picked. Everyone who can browse that project can read it. By default it names flows by their ids only, and it links to the Usage page. TuneCraft keeps the people's account ids while they are picked, and each alert sent with its work item key for 400 days. Jira writes to admins itself at 80% and 100% of the steps actually used.

Questions about the app? Write to info@plugincraft.ca.