📣 Retrying automation rules for enhanced reliability

[#1]

Over the next few weeks, we'll be rolling out a new Atlassian Automation enhancement across all products and editions, designed to increase the reliability of your rules. Automation will now attempt to retry Automation rules that have been stopped by temporary system issues, ensuring that your workflows continue to run smoothly without interrupting your team.

What causes a rule to be retried?

Understanding the difference between configuration and system errors is key to knowing when rules may be retried. Configuration errors arise from issues in setting up the components in your rule (e.g. Creating a work item in a project that has been deleted) or changes in external systems (such as when the Send Web Request action points to a deprecated third-party API endpoint). These types of errors will not trigger an automatic retry.

Conversely, system errors are temporary interruptions within the Atlassian platform, such as brief service outages. For instance, if you have an Automation that transitions a work item from one status to another based on specific conditions, and it halts mid-run due to a transient error, Automation may attempt to retry the rule from the point of interruption. This process continues until either the action is successfully executed, or the 7-day retry window expires from the time of the initial error. The mechanism to retry rules itself does not contribute to the processing time for a rule - only the time to process the actions taken do. To learn more about when a rule may be retried from a system error, check out the support documentation here.

Tracking when rules are retried

Typically, when rule retry is working it will go unnoticed. However, you can view which rules are queued for retry and which have been successfully retried in the Audit Log. There are three statuses you may encounter:

Queued for retry - new status

When a rule stops due to a system error and is waiting or in the process of being retried, it will have the status queued for retry. To find out exactly where the rule stopped, click 'Show more' to view the component that stopped.

Successfully retried - existing status

If a rule was interrupted due to a system error and subsequently retried successfully, it will show the existing success status. When you click ‘show more’, the component that was retried will display a circular arrow icon instead of a check mark, indicating it was retried.

Retried and failed - existing status

If a rule stopped due to a system error, was retried but the rule ultimately failed, it will show the existing failure status and details in ‘show more’.

Rule retry roll out

The rollout of rule retry will start on the 3rd of March, 2025. Initially, it will be gradually introduced with a select few components, with additional components to be added in the following weeks. As always, if you have any questions or feedback, please drop a comment below.

[Bill Sheboy]

Hi @Simon Chan 

Thank you for this information.  After reviewing the documentation page you linked to, I wonder...

1) Can this feature be disabled at a site, project, and / or rule level?

2) Which rule actions will be candidates for retry attempts: all of them or specific ones?

3) The 7-day retry window seems quite long for many rule usage scenarios.  Will that duration be configurable in the future?

4) Once a retry attempt is queued, can it be cancelled to prevent the rule from executing?  For example, in cases where the rule's successful completion is no longer relevant due to other changes.

5) Will the access and permissions of the rule actor / initiator be cached such that when the retry is attempted it will process in the same manner as the original attempt, or will the current settings be used for the actor / initiator?

6) The documentation indicates the retried rule will continue "from the point of failure".  Will all current rule state be used from that point forward in execution?  That is, trigger field values, trigger incoming webhook data, Lookup Issue results, Lookup Table contents, Created Variable values, Send Web Request response data, etc.  Or, will data be refreshed to the current values in the database, such as reloading the fields of issues?

7) What happens to queued retries when a rule is modified?  Will they be deleted, proceed with the state and definition of the rule before changes, try to continue if the failed rule action (by ID) still exists in the rule, etc.?

8) Will the new "Queued for Retry" be added the Status filters for the global automation audit log view?

9) When a rule retries and either succeeds or fails, the audit log is updated to that status.  How can customers use the global automation log to track the frequency of "Queued for Retry"?

10) When a rule retries and either succeeds or fails, how can customers later review which step had the temporary interruption?

11) Currently when there is an Atlassian outage impacting the running of automation rules, it is unclear to customers which rules will eventually trigger (or complete) execution or not.  This new retry capability impacts "temporary interruptions within the Atlassian platform, such as brief service outages."  What is the threshold at which to expect retries to happen versus the current environment.

Thank you in advance for your responses.

Kind regards,
Bill