Jira Automations Are Literally Programs

Engineering folklore has long whispered that Jira is Turing-complete. Nicolas Seriot finally proves it with a concrete reduction: a Minsky register machine built entirely in Atlassian Automation. The proof, published on 22nd May 2026, includes setup instructions and an execution trace.

Mapping the Computational Model

A Minsky register machine requires two unbounded counters and a finite set of labeled instructions. Seriot maps this onto Jira:

  • Register A: Count of linked issues of type Bug
  • Register B: Count of linked issues of type Task
  • Program Counter: Status of a single Epic issue
  • Dispatch Table: Jira Automation rules, one per instruction state
  • Clock: Automation-triggered transitions or external re-triggering past chain caps

INC and DEC are implemented as issue creation and deletion on the appropriate linked-issue type. Conditional branching uses JQL-conditioned rules.

Implementing Addition

Seriot provides a minimal working implementation using one Epic, five linked issues, and one Automation rule per instruction state. The workflow has statuses: BACKLOG, TODO, DEV, and PROD. Any state can transition to any other.

Rule for TODO (DEC A):

  • Trigger: Epic status changed to TODO.
  • If at least one linked Bug exists: delete one Bug, transition Epic to DEV.
  • Else: transition Epic to PROD (halt).

Rule for DEV (INC B):

  • Trigger: Epic status changed to DEV.
  • Create a new Task, link it to the Epic.
  • Transition Epic to TODO.

Both rules have "Allow rule to trigger other rules" enabled. With initial registers A=2 (2 Bugs) and B=3 (3 Tasks), bootstrapping the Epic to TODO triggers five transitions:

(2,3) TODO → (1,3) DEV → (1,4) TODO → (0,4) DEV → (0,5) TODO → (0,5) PROD

The Epic lands in PROD with 0 Bugs and 5 Tasks linked. 2 + 3 = 5. Recorded on a real *.atlassian.net instance.

Fibonacci in Three States

Seriot also demonstrates Fibonacci using three states (TODO, QA, DEV) and three registers (Bug, Task, Story). The key insight: Jira's Convert Issue Type operation (Bug → Story, Story → Task, etc.) can be expressed as DEC + INC, shrinking the dispatch table dramatically.

Fibonacci Logic:

  • TODO: if any Task exists, convert Task → Story, INC Bug, transition to TODO; else to QA
  • QA: if any Bug exists, convert Bug → Task, transition to QA; else to DEV
  • DEV: if any Story exists, convert Story → Bug, transition to DEV; else to TODO

Initial state A=1, B=1, C=0. The sequence 1, 1, 2, 3, 5, 8, 13… appears in B (Task count). The Fibonacci machine has no halt state; it runs until Jira Cloud's chain-depth cap of 10 triggers. The operator re-triggers the Epic to continue — a single status edit restarts the cascade. Jira Data Center exposes the same as automation.rule.execution.timeout and related configurable properties.

Conclusion

Jira's automation language can encode a two-counter machine given unbounded issue creation and rule execution. Every physical computer is finite, so Jira Cloud's finite quotas do not refute the construction. Under that standard convention, Jira is Turing-complete.

So, if complex Jira automations feel like programs, it's because they literally are.

What This Means for Developers

  • Treat automations with the rigor of code: version control, testing, and review.
  • Expect complexity: large automation setups may exhibit surprising computational behavior.
  • Know the limits: Cloud chain caps and timeouts are practical constraints, not theoretical refutations.