Jira-Automation-Regel löst nicht aus? Drei Ursachen, die Jira nicht meldet
Kein Fehler, kein fehlgeschlagener Lauf, nichts im Log — die Regel (Flow) lief einfach nie. Drei Ursachen, die Jira nicht meldet, und wie ihr sie findet.
Jemand meldet, dass eskalierte Tickets die Bereitschaft nicht mehr anpiepen. Ihr öffnet die Regel. Sie ist aktiv, die Bedingungen sehen richtig aus, und das Audit-Log zeigt überhaupt nichts — keinen Fehler, keinen übersprungenen Lauf, nichts. Die Regel ist nicht kaputt. Eine Jira-Automation-Regel (Jira nennt sie inzwischen Flow) hat aufgehört zu laufen auf die einzige Art, über die Jira euch nie informiert: Sie wurde nie aufgerufen.
Dafür gibt es drei strukturelle Ursachen, und keine davon erzeugt einen Fehler. Diese Anleitung erklärt jede einzelne, wie sie von außen aussieht und wie ihr alle Fälle auf eurer eigenen Instanz findet.
Der Schalter, der ab Werk aus ist
Eine Regel, die auf Vorgangsänderungen reagiert — Statuswechsel, Feldänderung, Kommentar —, ignoriert Änderungen, die andere Automation-Regeln vorgenommen haben, solange ihr es nicht ausdrücklich erlaubt. Die Einstellung heißt Allow flow trigger (Allow rule trigger auf älteren Instanzen), sie steht in den Einstellungen des Flows, und Jira liefert sie ausgeschaltet aus.
Diese Voreinstellung ist bewusst so gewählt und sinnvoll: Ohne sie könnte eine unachtsame Regel eine Kettenreaktion über die ganze Instanz auslösen. Der Preis ist, dass die Kette, die ihr am Whiteboard entworfen habt, erst existiert, wenn jemand in der empfangenden Regel ein Häkchen setzt — und nirgends meldet etwas, dass es fehlt. Die sendende Regel läuft, erledigt ihre Arbeit und meldet Erfolg. Sie war erfolgreich. Die zweite Regel wurde schlicht nie eingeladen.
Das ist eine häufige Ursache für eine „kaputte" Kette, die nie kaputt war.
Die Verbindungen einer Regel: was feuert, was nicht kann, und warum
Wie das in echter Größenordnung aussieht
Auf einer realen Jira-Cloud-Instanz — 1 214 Regeln in 98 Projekten, 884 davon aktiv — fand Automation Map 1 724 Regelpaare, die einander auslösen könnten, es aber nie tun, weil bei der empfangenden Regel Allow flow trigger aus ist. Diese 1 724 Möglichkeiten landen in 216 Regeln.
HINWEIS: Das ist keine Zahl kaputter Ketten, und wir stellen sie auch nicht so dar. Der Schalter ist standardmäßig aus, also waren die meisten dieser Paare nie als Kette gedacht — es sind schlicht zwei Regeln, die dasselbe Ereignis berühren. Interessant ist die Handvoll darin, die jemand absichtlich gebaut hat und die still nie lief. Nur wer die Absicht kennt, kann das unterscheiden — deshalb benennt die App den Schalter, statt von einem Fehler zu sprechen.
Eine Instanz ist kein Durchschnitt. Eure wird andere Zahlen liefern, und der Sinn der Zahl liegt im Verhältnis: Auf dieser Instanz feuern 293 Ketten tatsächlich, gegenüber 1 724 Möglichkeiten. Irgendwo in dieser Lücke stecken die Übergaben, die ihr bauen wolltet.
Wenn zwei Regeln auf dasselbe Ereignis antworten
Die zweite Ursache sieht aus wie das umgekehrte Problem: Etwas passiert zweimal. Ein Vorgang bekommt zwei Kommentare. Ein Feld wird gesetzt und sofort überschrieben. Ein Ticket wechselt den Status und springt zurück.
Wenn zwei oder mehr Regeln im selben Projekt auf dasselbe Ereignis hören, garantiert Jira keine Reihenfolge und warnt auch nicht vor der Überschneidung. Jede Regel für sich ist korrekt. Zusammen liefern sie sich ein Rennen, und der Sieger wechselt von Lauf zu Lauf — weshalb sich das Problem so schlecht reproduzieren und so leicht der falschen Regel anlasten lässt.
Dieselbe Instanz trägt 116 Gruppen von Regeln, die um ein Ereignis konkurrieren.
Wenn eine Regel sich selbst weckt
Die dritte Ursache ist eine Regel, deren eigene Aktion auf ihren eigenen Trigger passt. Sie bearbeitet einen Vorgang; die Bearbeitung ist eine Änderung; die Änderung startet die Regel erneut — sofern die Regel Trigger durch Automation zulässt, derselbe Schalter wie bei der ersten Ursache. Jira hat einen Schleifenschutz und stoppt Ausreißer, aber eine langsame Schleife — die ein paar Mal pro Vorgang feuert statt endlos — kostet einfach still Schritte und schreibt Rauschen in die Historie.
Ringe sind dasselbe über mehrere Regeln verteilt: A löst B aus, B löst C aus, C löst A aus. Auf derselben Instanz gibt es 25 Rekursionen — 21 Regeln, die in sich selbst zurücklaufen, und 4 Ringe über mehr als eine Regel.
Wie ihr eure findet
Die drei Ursachen haben eines gemeinsam: Sie sind alle in der Konfiguration eurer Regeln sichtbar, nicht im Protokoll ihrer Läufe. Ihr müsst also nicht warten, bis das Problem erneut auftritt.
- Öffnet in Jira Jira-Einstellungen → System → Automation flows, dann More actions (…) → Export flows (Export rules auf Instanzen, die die Umbenennung noch nicht erreicht hat). Jira lädt eine JSON-Datei mit allen Regeln der Instanz herunter.
- Ladet diese Datei in Automation Map. Die Karte wird im Hintergrund gebaut; eine Instanz mit tausend Regeln dauert ein bis zwei Minuten.
- Öffnet die verdächtige Regel und lest ihren Links-Tab: Ketten, die feuern, Ketten, die es nicht können, und jeweils den Grund. Bestätigt die Verbindungen, die absichtlich gebaut wurden, und verwerft den Rest.
- Für den Blick über die ganze Instanz lest die Zähler über der Karte — Live chains, Conflict groups, Recursion — und wählt diesen Verbindungstyp im Filter Any link, um die beteiligten Regeln zu sehen.
Die Karte eines Projekts, mit einem Zähler je Ursache
Nichts in diesem Ablauf verändert etwas in Jira. Die App liest den Export und berichtet; wenn ihr entscheidet, dass eine Kette existieren sollte, setzt ihr das Häkchen bei Allow flow trigger selbst — in Jira.
Was euch das nicht sagen kann
Es kann euch nicht sagen, ob eine Regel gestern gelaufen ist. Wie oft eine Regel läuft, steht in Jiras Performance insights; was ein einzelner Lauf getan hat, im Automation-Audit-Log, 90 Tage lang. Die App liest keines von beiden, und für das Audit-Log gibt es keine öffentliche API. Was die Struktur liefert, ist die engere Auswahl: welche Regeln es gewesen sein könnten und welche es nicht gewesen sein können, weil ihre Kette gar nicht feuern kann.
Für „ist sie wirklich gelaufen und was hat sie getan" ist Jiras eigenes Automation-Audit-Log das richtige Werkzeug — und darin besser als alles, was wir bauen könnten.
FAQ
Warum hat meine Jira-Automation-Regel ohne Fehler aufgehört zu laufen?
Oft lief sie nie. Eine Regel, die auf Vorgangsänderungen reagiert, ignoriert Änderungen anderer Regeln, solange in der empfangenden Regel Allow flow trigger (Allow rule trigger auf älteren Instanzen) nicht aktiv ist — und Jira liefert diesen Schalter ausgeschaltet aus. Die sendende Regel meldet Erfolg, die empfangende wird nie aufgerufen, und nichts wird als Fehler protokolliert.
Was macht Allow flow trigger genau?
Es erlaubt einer Regel, auf Änderungen durch Automation zu reagieren statt nur auf Änderungen durch Menschen. Ohne den Schalter sieht ein Statuswechsel, den eine andere Regel ausgelöst hat, für die empfangende Regel aus, als sei nichts geschehen.
Wie finde ich alle blockierten Übergaben auf meiner Instanz?
Exportiert die Regeln über Einstellungen → System → Automation flows → Export flows und ladet die Datei in Automation Map. Der Links-Tab jeder Regel trennt die Ketten, die feuern, von denen, die es nicht können, und benennt den verantwortlichen Schalter.
Warum läuft meine Jira-Automation zweimal?
Zwei oder mehr Regeln hören auf dasselbe Ereignis am selben Ort. Jira garantiert keine Reihenfolge und warnt nicht vor der Überschneidung, deshalb ändert sich das Ergebnis von Lauf zu Lauf — die übliche Ursache für doppelte Kommentare und überschriebene Felder.
Wie verhindere ich, dass eine Regel sich selbst auslöst?
Lasst Allow flow trigger aus, wenn die Regel nicht auf andere Regeln reagieren muss. Andernfalls grenzt den Trigger so ein, dass die eigene Aktion der Regel nicht darauf passt — auf ein bestimmtes Feld triggern statt auf jede Aktualisierung, oder eine Bedingung ergänzen, die den von der Regel selbst erzeugten Zustand ausschließt. Jiras Schleifenschutz stoppt Ausreißer, eine langsame Schleife kostet aber still Schritte.
Kann eine App mir sagen, warum eine Regel gestern lief?
Nein. Wie oft eine Regel lief, steht in Jiras Performance insights, was ein Lauf getan hat, im Audit-Log (90 Tage) — dafür gibt es keine öffentliche API, also liest es keine App außerhalb von Jira. Eine strukturelle Karte grenzt auf die Regeln ein, die infrage kommen; das Audit-Log bestätigt, welche es war.
Verändert das Auslesen meiner Regeln etwas in Jira?
Nein. Automation Map liest einen Export und berichtet darüber. Jede Korrektur, die sie benennt — Allow flow trigger einschalten, einen Trigger eingrenzen, eine konkurrierende Regel entfernen —, führt ihr selbst in Jira aus.
Findet die Ketten, die nie feuern
Die Regeln, die ihr gebaut habt, sind nicht verloren. Sie stehen in einer Instanz, in der nichts meldet, welche der Übergaben, die ihr bauen wolltet, nie feuern können — und ein Export genügt, um zu sehen, welche.
👉 Automation Map für Jira — seht, welche Regel welche auslöst