Rule Execution History

The Jira Automation audit log records every rule run. ajat audit-log brings it into an export directory, so ajat report risk can see how your rules actually behave, not only how they are configured:

• which rules Jira throttled for breaching a service limit;
• which rules keep running without doing anything;
• which runs touched hundreds of work items;
• which rules run the most, beside their risk score.

Jira bills automation by the step, and its usage page gives the total without saying why. Execution history is what turns the risk report into a cost review: a rule that runs thousands of times and almost never performs an action is the cheapest saving on the estate. Available from v1.0.8.

Two ways in

Both write the same file, and the risk report reads it the same way.

Use import when you want to stay on Jira’s supported features, or to look at a few rules. Use fetch to cover the whole site without exporting by hand.

Import CSV exports

Export the CSV from Jira

1. Open the Automation audit log. For the whole site, go to Settings › System › Automation rules and open the Audit log tab; this needs Jira admin rights. For one project, go to Project settings › Automation › Audit log. For one rule, open the rule and its audit log.
2. Set the filters, such as the date range, to what you want to analyse.
3. Choose the CSV export from the … menu. The file holds every entry that matches the filters.

Import it

ajat export --output-dir ./jira-automations-backup
ajat audit-log import --input-dir ./jira-automations-backup ~/Downloads/automation-audit-logs-*.csv
ajat report risk --input-dir ./jira-automations-backup --output-file risk.html

• Several files are merged. A run that appears in two files is counted once, so overlapping exports are safe.
• Only what the files hold. Statistics cover the rules and the days in the files. Rules that are not in any file have no statistics, and the report says the data comes from a CSV import.
• Configuration changes are not runs. The export also lists edits to a rule (CONFIG_CHANGE). They are left out of every count.
• Dates follow the browser’s locale. The command tells day-first from month-first dates itself. If every date in a file could be read either way, it asks for --date-order.
• Times follow your Jira profile’s time zone. Pass --timezone when that is not UTC. The time zone only shifts the window’s edges by a few hours; it changes no finding.
• Rules missing from the export are reported. If the files name rules the export does not contain, the command says how many. That usually means a stale export or the wrong --input-dir.

The import uses only Jira’s own export, so it is not experimental.

Fetch from Jira (experimental)

ajat audit-log fetch reads recent runs straight from the audit log, for every rule on the site.

ajat export --output-dir ./jira-automations-backup
ajat audit-log fetch --input-dir ./jira-automations-backup
ajat report risk --input-dir ./jira-automations-backup --output-file risk.html

How long a fetch takes

The log comes back newest first, 50 runs per request, and each request is slower the further back it reaches (about a third of a second for the newest runs, several seconds three months back). The window, not the whole retention, therefore sets the cost. The default of 15 days matches the “runs without actions” check below; pass --days 30 for a longer view.

Measured on a real site with about 4,100 rule runs a day:

That run found 2 throttled rules, 96 rules running without actions, and 8 rules whose runs touched 100 or more work items; the four busiest rules ran about 4,300 times each in 15 days, and 99% of those runs performed no action.

More workers fetch faster but put more load on Jira; 4 is a good start. Progress is shown on stderr unless you pass --no-progress.

The statistics file

Both commands write one file, .ajat_audit_stats.json, at the root of the export. It holds per-rule counts, not the raw log: runs, runs per outcome, runs that performed an action, the latest run, the latest run that did something, and the most work items a single run touched. Run either command again to refresh; it replaces the file, and import says when it replaced statistics that were already there. Like the export’s other hidden files, it is never mistaken for a rule by any command.

What the risk report does with it

A Busiest rules table ranks the 20 rules with the most runs in the window, with how many of those runs did nothing, how many were throttled, the most work items one run touched, and the rule’s risk score. A busy rule whose runs mostly perform no action is usually the cheapest saving: a narrower trigger or an earlier condition stops it from running at all.

Without the statistics file, the two execution findings show “run ajat audit-log import or fetch to enable this check” and the table is not shown. The table is badged CSV import or experimental by where the statistics came from.

What the numbers mean

• Runs, not steps. Jira bills automation in steps (each trigger, condition, action, and branch iteration that runs). ajat counts runs, not steps. They rank rules reliably; they are not your bill. Jira’s usage page in Settings › System › Automation is the billed figure.
• “Performed an action” means the run’s outcome was Success or Some errors. No actions performed means a condition stopped the run.
• An observation of the window. A rule that did not run in the window has no statistics. A fetch pages over a live log and can miss a handful of runs that arrive while it reads; an import counts exactly the rows in its files. Counts are good for ranking and thresholds, not for auditing an exact figure.
• Your account’s view. The log shows what the configured account, or the person who exported the CSV, can see.

Troubleshooting

• “not an automation audit-log export: missing column(s)” — the file is not an audit-log CSV, or it was edited. Export it again from the audit-log page and pass it unchanged.
• “cannot tell whether dates are day first or month first” — every date in the file reads both ways, such as 03/04/2026. Pass --date-order dmy or --date-order mdy.
• “Jira’s internal audit-log endpoint did not answer as expected” — Atlassian has changed the endpoint. Reports keep working without execution history; export the audit log as CSV and use import instead, and tell support@climakers.com.
• “The audit log ended before the start of the window” — your site’s log holds less than --days of history (for example a new site); the statistics cover the shorter period, and the report says how many days.
• It is slow. Lower --days, or raise --workers a little.

Related

• Risk — the risk report and every finding.
• Probing search sizes — --probe-jql measures searches before they run; the audit log shows what runs actually touched.
• Automation cost review — the recipe that puts both together.
• Utilities — doctor, tree, support, and the rest of the diagnostic surface.