The shift to usage-based pricing
Atlassian announced that some fixed features are moving to usage-based quantities, such as Automation runs, Rovo credits, and more.
According to the documentation, this change starts on for new instances and monthly paid instances. For annual instances, the new method starts in the next billing cycle at renewal.
I see this as good news. Many customers on Standard editions have complained about the number of automation rules available per user. Usually, it is not enough when you want to automate more, but you don’t want to buy the next edition just for that.
The practical challenge for Jira admins
This usage-based pricing can benefit customers who want to get more value from their current costs with more automation. For Automation flows, also known as rules, charges will now be based on the number of steps executed each time a flow is triggered. Unlike in the recent past, triggers will also count even when the rule conditions are not met and the rest of the flow does not continue.
On the other hand, there is another caveat that is not always easy to see today: we currently do not have a native feature to analyze our rules, identify the steps, count them, and estimate possible consumption. Because of this pricing change, complex flows — especially the ones that took a long time to set up, were split into different triggers, or accumulated extra actions over time — should now be reviewed carefully.
My current setups have at least 300 to 500 active rules. I heard a colleague mention an instance with 3,000 active rules. Imagine trying to analyze all of that manually.
The hidden inefficiencies
Because of my own needs, I started thinking about an app that would show the steps in each rule and highlight opportunities to improve the count. For example, many of us add log actions while testing a flow, retrying behavior, collecting error messages, or troubleshooting conditions. But do we still need those log actions after the flow is finished? How many of them remain in our rules simply because we never went back and removed them?
Automation Usage & Risk Analyzer for Jira
We built something simple, local, and free to help during this transition period. The goal is to support teams in reducing costs, understanding patterns, and estimating potential step counts before usage-based pricing becomes a bigger concern.
We call it Automation Usage & Risk Analyzer for Jira. It is approved and listed in the Marketplace, and you can install it for free in your instance:
https://marketplace.atlassian.com/apps/2915436104/automation-usage-risk-analyzer-for-jira
The app is designed to stay free forever because we built it to incur no costs on the Forge platform.
Some of the features are a starting point to help customers, Jira admins, consultants, partners, and teams get clearer and more actionable information about their automation flows:
- Local Jira Automation JSON import and analysis
- Automation inventory and rule structure analysis
- Risk and governance findings with evidence
- Step and service-limit analysis with clear separation from actual runtime usage
- Detection of unsupported or unknown Automation components
- Privacy-safe processing with sensitive-value redaction
- Browser-local analysis with no raw source persistence and no API token required
- Support foundation for audit-log analysis, dependency mapping, impact analysis, optimization, comparison, and reporting
What it analyzes today, and why feedback matters
The analyzer works from the Jira Automation JSON export and the Flow audit log CSV export. In other words, it reads the exported files and configuration locally in the browser to map triggers, conditions, branches, actions, and potential step complexity. This is a static structural analysis of the export, not a replacement for Atlassian’s runtime usage reports, so it should be used to identify likely cost drivers and review priorities before comparing results with actual admin reporting.
This first version focuses on validating compatibility, accuracy, performance, and usability across different Jira Automation estates. We expect a lot of feedback and adjustments to the calculation logic. For example, some step types, or where they are placed in the rule structure, cannot always be counted as a single known step count through static analysis alone.
One example is an if/else chain. Static analysis can estimate potential execution paths and identify where steps may occur, but it does not represent exact runtime history. Depending on the rule structure, billing may count one path or multiple potential branches, but actual execution depends on the conditions met at runtime.
We at iDev hope this helps the Atlassian Community, users, customers, admins, consultants, and partners prepare with more visibility and confidence.
Please share any feedback and changes needed to match the exact count Atlassian Admin shows in the report.
Analyze Jira Automation usage, risks, dependencies and optimization opportunities locally
Details for every rule
You get information about the details, and what steps counted or not to your usage
See the usage towards your rules configuration
Match the step cound Atlassian is informing in Admin portal
Check the risks and expor result
Check some of the risks in your rules and fix what is needed
More details
Automation Usage & Risk Analyzer for Jira helps administrators understand, audit, and optimize Jira Automation without connecting to unsupported Automation APIs.
Import Jira Automation JSON exports to analyze rule inventory, structure, component usage, risks, dependencies, configuration references, and optimization opportunities. Where supported, Automation audit-log CSV files can also be analyzed to correlate observed executions, no-action activity, fan-out, and step usage.
Analysis runs locally in the browser. Raw source files are not persisted, and no Atlassian API token or service account is required.
The analyzer keeps configured structure, service limits, potential execution, and observed usage clearly separated. Findings include evidence and confidence where appropriate, helping administrators investigate issues without presenting estimates as actual billed usage.
