So senkt ihr den Schrittverbrauch von Jira Automation — sechs Korrekturen
Eine Log-Aktion bei jedem Lauf. Ein erneuter Abruf, obwohl sich nichts geändert hat. Eine Bedingung, die der Trigger gratis erledigt hätte. Jede ist leicht aus einer Regel (Flow) zu entfernen — und ab Dezember abgerechnet.
Die meisten Regeln (Jira nennt sie inzwischen Flows), die Geld verschwenden, sind nicht schlecht entworfen. Sie wurden schnell geschrieben, mit einer Log-Aktion debuggt, zweimal erweitert und nie wieder gelesen. Die Verschwendung steckt in der Reihenfolge der Schritte, nicht in der Absicht.
Ab dem 3. Dezember 2026 taucht diese Verschwendung auf einer Rechnung auf: Atlassian rechnet Jira Automation nach Schritten ab, zu 0,50 $ pro 1 000 Schritte oberhalb des Kontingents eurer Organisation. Diese Anleitung zeigt sechs Muster, die Schritte ohne Ergebnis kosten, warum sie entstehen und was dagegen hilft. Auf einer realen Instanz fand die App 505 von 5 443 Schritten — etwa jeden elften, verteilt auf 225 Regeln —, die solche Korrekturen entfernen könnten.
1. Eine Log-Aktion, die jedes Mal läuft
Jemand fügte Log action ein, um ein Fehlverhalten zu verstehen, behob es und ließ das Log stehen. Es läuft jetzt bei jeder Ausführung, für immer, und niemand liest die Ausgabe.
Korrektur: löschen. Wenn ihr die Spur bei einer wirklich kniffligen Regel behalten wollt, verschiebt sie hinter die Bedingung, die den interessanten Fall unterscheidet — dann läuft sie nur auf dem Pfad, der euch interessiert.
2. Ein erneuter Abruf, obwohl sich nichts geändert hat
Re-fetch work item data gibt es aus einem Grund: etwas außerhalb der Regel hat den Vorgang geändert und die Regel braucht die neuen Werte. Wenn zwischen Trigger und Re-fetch nichts den Vorgang angefasst hat, bringt der Schritt nichts.
Korrektur: Re-fetches entfernen, denen nur Schritte vorausgehen, die den Vorgang nicht verändern. Einen direkt nach Work item created behalten, wenn spätere Schritte Felder lesen, die beim Erstellen gesetzt wurden — ebenso nach einem Statusübergang oder einem externen Aufruf.
3. Eine Bedingung, die der Trigger gratis erledigt hätte
Eine Regel löst bei Work item transitioned aus und prüft dann als erste Bedingung, ob der neue Status „Done" ist — der Zielstatus-Filter des Triggers erledigt das gratis. Oder eine Regel auf Work item updated, deren erste Bedingung ein einzelnes Feld prüft — ein Field value changed-Trigger auf dieses Feld tut dasselbe.
Ein filternder Trigger kostet denselben einen Schritt, ob er zutrifft oder nicht, und die Bedingung, die er ersetzt, war ein zweiter Schritt in jedem Lauf.
Korrektur: den Filter in den Trigger verschieben. Der Lauf endet am Trigger statt an einer bezahlten Bedingung.
Kosten-Befunde nennen die Änderung und ihre Einsparung
4. Bedingungen nach Aktionen
Eine Regel bearbeitet den Vorgang, schreibt einen Kommentar — und prüft danach, ob der Vorgang überhaupt im richtigen Status ist. Scheitert die Prüfung, sind Bearbeitung und Kommentar längst passiert: bezahlt, und womöglich zurückzunehmen.
Korrektur: Jede Bedingung, die nicht vom Ergebnis einer Aktion abhängt, gehört über die erste Aktion. Das ist das einzige Muster hier, das nicht nur ein Kosten-, sondern auch ein Korrektheitsfehler ist.
5. Mehrere Bearbeitungen desselben Vorgangs hintereinander
Drei Edit work item-Aktionen in Folge, jede setzt ein Feld, weil sie an drei verschiedenen Tagen ergänzt wurden. Eine einzige Bearbeitung kann alle drei Felder setzen.
Korrektur: zusammenführen. Aus drei Schritten wird einer, und der Vorgang bekommt eine Änderung in der Historie statt drei — womit auch drei separate Änderungsereignisse entfallen, die sonst alles aufwecken, was in diesem Projekt lauscht.
6. Ein Zeitplan, der alles neu durchsucht
Eine geplante Regel läuft auf einem JQL, das jeden Vorgang des Projekts zurückgibt, und eine Bedingung in der Schleife pickt die wenigen heraus, die zählen. Aus tausend Vorgängen werden jede Nacht tausend Bedingungsschritte.
Korrektur: den Filter in das JQL des Zeitplans ziehen — oder Only include work items that have changed since the last time this flow executed ankreuzen; genau darauf zeigt der Befund der App. Die Schleife iteriert dann über die Treffer statt über alles, und die Kosten sinken auf das, worauf die Regel tatsächlich wirkt.
Die anderen sieben
Automation Map prüft dreizehn solcher Muster, nicht sechs. Die übrigen sind spezieller: Regeln, die nur loggen, Bedingungsketten, die eine JQL-Bedingung ersetzen könnte, instanzweite Regeln, die nur in wenigen Bereichen (Projekten) je etwas tun, Zeitpläne, die ein Dutzend Mal am Tag oder öfter feuern, Verzweigungen als Ja/Nein-Prüfung, einmal benutzte Variablen und konstante Bearbeitungen, die eine Post-Function oder ein Feldstandard erledigen könnte. Jeder Befund benennt den Schritt und begründet, warum er entfernbar ist; die meisten sagen, wie viele Schritte die Korrektur spart.
HINWEIS: Jeder Befund ist ein Vorschlag zur Prüfung, keine automatische Änderung. Die App bearbeitet eure Regeln nie — sie arbeitet mit einem Export, den ihr hochladet, und hat keine Berechtigung, in Jira etwas zu ändern. Ihr lest den Befund, entscheidet und ändert selbst in Jira.
Was das wert ist
Auf einer realen Instanz kam ein Lauf jeder aktiven Regel auf rund sechs Schritte je Regel, und jeder elfte davon könnte entfallen. Multipliziert mit der tatsächlichen Laufhäufigkeit — die steht in Jiras Performance insights, die kein Werkzeug außerhalb von Jira liest — ergibt sich die Jahreszahl.
Was ihr vor Dezember bekommen könnt, sind die Kosten eines Laufs, je Regel, mit benannten entfernbaren Schritten.
FAQ
Wie finde ich verschwendete Schritte in meinen Jira-Automation-Regeln (Flows)?
Exportiert eure Regeln über Einstellungen → System → Automation flows → Export flows und ladet die Datei in Automation Map. Jede Regelkarte listet die Schritte eines Laufs und welche davon dreizehn Detektoren als entfernbar markieren.
Ändert das Entfernen dieser Schritte, was meine Regeln tun?
Bei den obigen Mustern nicht — eine übrig gebliebene Log-Aktion, ein überflüssiger Re-fetch oder zusammengeführte Bearbeitungen liefern dasselbe Ergebnis günstiger. Die Ausnahme sind Bedingungen nach Aktionen: das zu beheben ändert das Verhalten, weil die Regel aufhört, Vorgänge anzufassen, die sie nie hätte anfassen dürfen.
Kann der Trigger das Filtern übernehmen?
Oft: Ein Work item transitioned-Trigger filtert nach Von- und Zielstatus, und Field value changed beobachtet benannte Felder. Beides ersetzt eine erste Bedingung und spart in jedem Lauf einen Schritt.
Wie viel kann ich erwarten zu sparen?
Auf einer realen Instanz mit 884 aktiven Regeln könnten bis zu 505 von 5 443 Schritten je Durchlauf entfallen — etwa 9 %, auf 225 Regeln verteilt. Eine Instanz ist kein Durchschnitt; nehmt das Verhältnis als Größenordnung, nicht als Zusage.
Ändert die App meine Regeln selbst?
Nein. Sie arbeitet mit einem Export, den ihr hochladet, und hat keine Berechtigung, in Jira etwas zu ändern. Befunde sind Vorschläge mit offengelegter Begründung; die Änderung macht ihr in Jira.
Warum nennt ein Werkzeug nur Schritte und kein Geld?
Geld ist Schritte mal Häufigkeit. Die Häufigkeit steht in Jiras Performance insights (Ausführungen je Flow) und im Audit-Log, für die es keine öffentliche API gibt — kein externes Werkzeug liest sie. Die Schritte stehen in der Konfiguration und lassen sich exakt zählen.
Fangt bei den teuren an
Ihr müsst keine tausend Regeln durchsehen. In Advanced sortiert die Audit-Seite jede Regel nach dem, was ihre Korrekturen sparen würden.
👉 Automation Map für Jira — findet die Schritte, die sich lohnen