Jira ships with a native automation engine that most teams barely use. The default examples it ships with are generic enough to be nearly useless: "auto-close issues after 30 days" and "assign new issues to the project lead." These rules exist but they do not reflect how engineering and ops teams actually work.
The rules that actually save time are specific to workflows that have real friction: triage that happens manually every morning, status updates that no one remembers to make, sprint reports that take an hour to compile each Friday. This post covers 12 rules I have seen working in production, with the trigger condition, rule logic, and measurable impact for each one.
A Quick Note on Jira Automation Pricing
Jira automation is included in all paid Jira Cloud plans. Jira Software Standard ($7.75 per user per month) includes 500 rule runs per user per month, which means a 20-person team gets 10,000 rule runs per month. That is enough for most teams. Premium ($15.25 per user per month) includes unlimited rule runs.
Rule runs are counted per rule execution, not per action within a rule. A single rule that fires on a trigger and then performs five actions still counts as one rule run. This is more generous than it sounds and means most teams never hit their limit on Standard.
ScriptRunner, which I will cover at the end, adds approximately $6 per user per month minimum on Jira Cloud and significantly more for larger teams. It is worth the cost for complex cases but is overkill for most of the rules below.
Triage and Assignment Rules
Rule 1: Auto-assign by component owner
Trigger: Issue created with a specific component set.
Condition: Component field is not empty AND issue is unassigned.
Action: Assign issue to the component lead as defined in the component configuration.
Jira's component system lets you set a default assignee for each component. This rule fires that assignment automatically on creation rather than requiring a human to read the incoming ticket and make the decision. For a 20-person engineering team with five active components, this eliminates 10–20 manual triage decisions per day. The cumulative impact is 30–60 minutes recovered at the start of each standup cycle.
Edge case to handle: if a ticket has multiple components, the rule fires on the first component only. Define a priority order in your component setup and document it so the team understands why tickets go where they do.
Rule 2: Priority escalation on comment from manager
Trigger: Comment added to issue.
Condition: Comment author is a member of the "Managers" user group AND current priority is not High or Highest.
Action: Set priority to High. Send notification to current assignee: "Priority escalated based on management comment. Please review."
This rule is counterintuitive at first: it is not about automation efficiency, it is about signal propagation. When a director or VP comments on a ticket, the team needs to know that the ticket now has executive visibility. Bumping the priority automatically and notifying the assignee ensures that visibility translates into action rather than disappearing into the comment stream.
One caution: this rule works well when managers comment intentionally on issues they care about. It misfires if managers use comments casually. Scope it with a keyword trigger ("ESCALATE:" at the start of the comment) if your team has informal commenting habits.
Rule 3: Auto-label by keyword in issue summary
Trigger: Issue created.
Condition: Summary contains any of: "security", "compliance", "prod", "urgent", "outage".
Action: Apply corresponding label (security-review, compliance, production-incident, urgent, outage).
Labels applied at creation make filtering dramatically easier. A security team can maintain a filter "label = security-review AND status != Done" to see all open security-related items across all projects without manually curating them. The rule runs at creation speed and requires zero human attention once configured.
Build the keyword list carefully and review it quarterly. Keywords that are too broad ("issue" in the summary would label everything in a project called "Jira Issues") will create noise rather than signal.
Rule 4: Unassigned issue alert
Trigger: Scheduled trigger (daily at 9:00 AM).
Condition: Issue is in an active sprint AND issue is unassigned AND issue has been unassigned for more than 24 hours.
Action: Send Slack message to team lead channel: "Unassigned sprint items: [issue list with links]."
Unassigned issues in active sprints are one of the most common causes of sprint failure. They exist in an ownership vacuum: everyone assumes someone else will pick them up. This rule creates a daily pull rather than a push: the team lead gets a list every morning and can assign or reassign in under two minutes. The rule does not reassign automatically (which can create confusion), it just ensures visibility.
Status and Workflow Rules
Rule 5: Auto-start when PR linked
Trigger: Development panel updated (pull request created or linked).
Condition: Issue is in "To Do" status AND a pull request is now linked.
Action: Transition issue to "In Progress." Add comment: "Status automatically moved to In Progress when pull request was linked."
This rule eliminates one of the most common status hygiene failures: a developer opens a PR but forgets to move the ticket. The issue sits in "To Do" while the work is already in review, making sprint boards misleading. The auto-start rule keeps the board accurate without requiring developers to remember a separate administrative step.
Requires Jira's GitHub or Bitbucket integration to be active. Works out of the box if your team uses Jira's built-in development panel.
Rule 6: Auto-close when PR merged
Trigger: Development panel updated (pull request merged).
Condition: Issue is in "In Progress" or "In Review" status AND linked pull request is now merged.
Action: Transition issue to "Done." Log work time based on time spent in "In Progress." Add comment: "Issue automatically closed when linked pull request was merged."
This rule works well for teams with a clean one-to-one relationship between tickets and PRs. It breaks down when a single PR closes multiple issues (use multiple "Closes #X" references in your PR body to trigger multiple automations) or when a ticket requires post-merge work (add a post-deploy verification subtask as part of the Done transition action).
The work log automation requires the Time Tracking feature to be enabled on the project. If your team does not use time tracking, remove that action from the rule.
Rule 7: Parent epic auto-update
Trigger: Issue transitioned (to "Done").
Condition: Issue is a child of an epic AND all other child issues of that epic are now in "Done" status.
Action: Transition parent epic to "Review." Add comment to epic: "All child issues completed. Epic moved to Review for sign-off."
Without this rule, epics drift open indefinitely even after all their work is complete. Someone has to periodically audit epics and close the ones that are done. This rule makes epic status accurate automatically and creates a natural review checkpoint before epics are closed. Teams that review their roadmap against epics weekly find this rule saves a 15–20 minute manual audit each week.
Rule 8: Stale in-progress alert
Trigger: Scheduled trigger (daily at 8:30 AM).
Condition: Issue is in "In Progress" status for more than 5 business days AND no comment has been added in the last 3 business days.
Action: Add label "stale-in-progress." Send Slack notification to assignee: "Issue [KEY] has been In Progress for 5+ days with no update. Please add a comment or move the status."
The stale-in-progress problem is a leading indicator of two things: blockers that were not escalated, and work that is actually done but was never transitioned. This rule surfaces both. Assignees who are blocked respond with what they are waiting for (creating visibility). Assignees who forgot to close the ticket close it. Both outcomes improve sprint accuracy.
The combined condition (5 days stale AND no recent comment) reduces false positives. An issue that someone commented on yesterday is clearly getting attention even if the status has not changed.
Reporting and Visibility Rules
Rule 9: Sprint close digest
Trigger: Sprint completed.
Condition: Sprint is in the target project.
Action: Send Slack message to the team channel with: sprint name, count of completed issues, count of incomplete issues, and the list of incomplete issues carried forward (with links).
Most sprint retrospectives start with someone pulling up Jira and counting completed vs incomplete issues manually. This rule does that automatically at sprint close and sends the summary to Slack, where the team already is. The digest takes 30 seconds to read instead of 5 minutes to compile. Teams using this rule report that retrospectives start faster and focus more quickly on the root cause of incomplete items rather than the inventory.
The Sprint Completed trigger is available in Jira automation natively. The message format uses Jira's Smart Values to construct the list dynamically: {{#issues}}• {{key}}: {{summary}} ({{assignee.displayName}}){{/issues}}.
Rule 10: SLA breach warning
Trigger: Scheduled trigger (every 30 minutes).
Condition: Issue has an SLA field AND remaining time is less than 2 hours AND issue is not in "Done" status.
Action: Send Slack DM to assignee. If remaining time is less than 30 minutes, also notify the team lead.
This rule requires Jira Service Management (JSM) or a custom SLA field on standard Jira. For JSM teams, SLA fields are built in and automatable. For standard Jira teams, you can approximate this with a custom date field for "SLA Due" and compute remaining time using Jira's Smart Values date arithmetic.
The two-hour and 30-minute thresholds work for most teams. Adjust based on your SLA windows: if your SLA is 4 hours, a 2-hour warning at the halfway point is appropriate. If your SLA is 24 hours, set the warning at 6 hours remaining.
Rule 11: Bug to post-mortem link
Trigger: Issue transitioned (to "Done").
Condition: Issue type is "Bug" AND priority is "Critical" or "Highest."
Action: Create a new linked issue of type "Task" with summary "Post-mortem: [original bug summary]" in the same project and epic. Link the original bug as "is post-mortem of." Assign the new task to the bug reporter. Set due date to 3 business days from today.
High-severity bugs get closed and forgotten. This rule forces a post-mortem task to exist before the bug is considered truly done. The 3-business-day due date creates urgency while giving the team time to gather data. The reporter is assigned by default because they typically have context on the impact, but any team member can reassign.
Teams using this rule consistently run more post-mortems without any additional process overhead. The automation makes the follow-through automatic rather than optional.
Rule 12: Release notes draft
Trigger: Version released (Jira version marked as released).
Condition: Released version has issues with the label "release-notes."
Action: Create a Confluence page in the designated Release Notes space with: version name, release date, and a table of all Done issues in the version that have the "release-notes" label (key, summary, type, assignee).
Release notes preparation is one of the most time-consuming recurring tasks in product and engineering. Collecting completed issues, formatting them, and publishing to Confluence typically takes 45–90 minutes per release. This rule reduces that to less than 5 minutes: someone reviews the auto-generated Confluence page, edits the summary paragraph, and publishes. The table of issues is accurate because it is pulled directly from Jira at release time.
The "release-notes" label creates an intentional filter. Not every bug fix belongs in release notes, and this system lets developers flag which ones do as they close them, rather than having someone retrospectively sort through all closed issues.
| Rule | Category | Estimated time saved per week |
|---|---|---|
| Auto-assign by component | Triage | 30–60 min (20-person team) |
| Priority escalation on manager comment | Triage | Variable (prevents missed escalations) |
| Auto-label by keyword | Triage | 20–40 min (filtering + audit) |
| Unassigned issue alert | Triage | 15–30 min (daily audit replaced) |
| Auto-start when PR linked | Workflow | 10–20 min (developer admin) |
| Auto-close when PR merged | Workflow | 10–20 min (developer admin) |
| Parent epic auto-update | Workflow | 15–20 min (epic audit) |
| Stale in-progress alert | Workflow | Variable (prevents sprint failures) |
| Sprint close digest | Reporting | 30–60 min (retrospective prep) |
| SLA breach warning | Reporting | Variable (prevents SLA breaches) |
| Bug to post-mortem link | Reporting | 20–40 min (post-mortem setup) |
| Release notes draft | Reporting | 45–90 min per release |
Debugging Your Rules
Jira automation provides an audit log for every rule execution under Automation → Audit Log. Each entry shows whether the rule fired, which conditions passed or failed, and which actions were executed. This is the correct place to start when a rule is not behaving as expected.
The three most common failure modes:
Rule fires but condition not met. The trigger fires (you see an entry in the audit log) but the condition block evaluates to false. Check the condition carefully: field comparisons in Jira automation are case-sensitive, and "In Progress" is not the same as "in progress." Check the exact field values on real issues before writing condition logic.
Action fails with permission error. The automation user does not have permission to perform the action on the target project or issue. Jira automation rules run as either the "Automation for Jira" user or a specific user you designate. Ensure the user has the correct project role for every action in the rule.
Webhook or API call times out. Rules that call external systems (Slack via webhook, external APIs via Send Web Request) can time out if the target endpoint is slow or unavailable. Build retry logic into the external system, not the Jira rule — Jira automation does not support native retry on action failure.
When Native Jira Automation Is Not Enough
Native Jira automation handles the 12 rules above well. It becomes limiting in three specific scenarios.
Complex conditional logic
Jira's native rule builder supports if/else branching via the "Condition" and "Branch" blocks. Once you need more than three or four conditional paths with different actions in each branch, the rule becomes difficult to read and maintain in the visual builder. ScriptRunner (Groovy-based) lets you write that same logic as code, which is more maintainable for complex rules.
Cross-issue data aggregation
Native automation handles single-issue context well. It struggles with rules that need to aggregate data across multiple issues simultaneously — for example, calculating the average cycle time across all issues in a sprint, or finding the most-assigned engineer across a project in the last 30 days. ScriptRunner can query the Jira API programmatically to aggregate this data.
External system integration with complex authentication
The native Send Web Request action handles simple REST calls with static headers. If the external system uses OAuth, rotated tokens, or requires a multi-step authentication flow before the actual API call, native automation cannot handle it. A custom integration via a lightweight bot or ScriptRunner is more reliable for these cases.
ScriptRunner adds roughly $6 per user per month at minimum on Jira Cloud and more for larger teams. Before investing in it, verify that the native automation builder genuinely cannot handle your use case. Most of the rules above, including their complexity, work in native automation without ScriptRunner.
Implementation example:
Team: 35 engineers · Rules implemented: 8 of the 12 above
Setup time: 3 days (including testing) · Zero ScriptRunner required
Estimated weekly time recovered: 4–5 hours across triage, status hygiene, and reporting
Frequently Asked Questions
How much does Jira automation cost?
Jira automation is included in all paid Jira plans at no additional cost. Jira Software Standard at $7.75 per user per month includes 500 rule runs per user per month. Premium at $15.25 per user per month includes unlimited rule runs. A 20-person team on Standard gets 10,000 rule runs per month, which is enough unless you have very high-frequency scheduled rules. ScriptRunner, for more advanced automation using Groovy code, costs an additional $6+ per user per month on top of Jira.
Can Jira automation replace Zapier?
Jira automation replaces Zapier for any workflow that stays within Jira and connected Atlassian products. It cannot replace Zapier for workflows that involve non-Atlassian systems unless you use the Send Web Request action to call external APIs directly. For teams that primarily need Jira-internal automation with occasional Slack notifications, native Jira automation handles the full workflow without Zapier. For complex cross-system integrations involving non-Atlassian tools, a lightweight custom bot or Make scenario paired with Jira automation is more maintainable than Zapier for Jira-centric workflows.
When should I use ScriptRunner instead of native Jira automation?
Use ScriptRunner when you need more than three conditional branches, when you need to aggregate data across multiple issues in a single operation, when external API calls require complex or rotated authentication, or when you need server-side access to Jira's full internal API rather than the public REST API. ScriptRunner runs Groovy code with full access to Jira internals. The learning curve is significant and the additional monthly cost is real, so verify that native automation genuinely cannot handle your use case before committing to it.
Build Your First Rule This Week
The single highest-ROI rule for most teams is Rule 1 (auto-assign by component) or Rule 9 (sprint close digest). Both are straightforward to configure in under 30 minutes and have a measurable impact on weekly meeting efficiency. Start with one, measure the impact for two sprints, then add the next rule that addresses your team's next-highest friction point.
Learn how we implement and optimize Jira automation for ops teams →
