Eine Jira-Regel prüft bei jeder Prioritätsänderung, ob ein Vorfall kritisch ist. Nur dann alarmiert sie das zuständige Team. Mit dem ursprünglich angekündigten Atlassian Automation Usage-Based Pricing hätten auch Prüfungen ohne anschließende Aktion das Kontingent belastet. Seit dem 5. November 2026 zählen solche Läufe nicht mehr.
Atlassian hat die Rückmeldungen zur ersten Ankündigung aufgegriffen. Das ist eine gute Nachricht für Teams, die ihre Regeln bewusst mit Bedingungen und klaren Zuständigkeiten aufgebaut haben. Trotzdem bleiben Verbrauch, Ausgabenlimits und betriebliche Folgen wichtige Aufgaben. Stand dieses Beitrags: 10. November 2026.
Vorher: Was die erste Ankündigung verändert hätte
Am 1. September 2026 kündigte Atlassian an, Automation nach ausgeführten Schritten statt nur nach Regelläufen zu messen. Trigger, Bedingungen, Aktionen, Verzweigungen und Schleifen bilden die neue Einheit. Die Kontingente berechtigter Apps werden organisationsweit zusammengeführt und monatlich erneuert.
Nach der ursprünglichen Ankündigung sollten auch Schritte aus Läufen ohne Aktion zählen. Bei häufigen Ereignissen hätte allein das Prüfen einer Bedingung Verbrauch erzeugt. Das hätte Teams dazu verleiten können, übersichtliche Regeln allein aus Kostengründen zusammenzulegen oder umzubauen. Gleichzeitig hätte ein Lauf mit vielen ausgeführten Aktionen mehr Schritte verbraucht als ein kurzer Lauf.
Unsere eigenen Jira-Automationen für einen Vertriebsprozess zeigen, warum das relevant ist: Bedingungen und getrennte Aktionen bilden unterschiedliche Aufgaben im Prozess ab. Verständliche Regeln sind für Wartung und Zuständigkeiten wichtig.
Jetzt: Keine Aktion, kein Verbrauch
Ein Rechenbeispiel aus der Dokumentation: Trigger, eigenständige Bedingung und Benachrichtigung ergeben drei Schritte, wenn die Aktion ausgeführt wird. Ist dieselbe Bedingung direkt im Trigger konfiguriert, sind es zwei. Der Unterschied betrifft Aktionspfade; stoppt der Lauf zuvor ohne Aktion, beträgt der Verbrauch in beiden Fällen null.
Mit dem Update vom 5. November korrigiert Atlassian diesen Punkt: Stoppt ein Lauf, bevor eine Aktion ausgeführt wird, zählen weder Trigger noch Bedingungen dieses Laufs. Im Audit-Log erscheint der Status „No actions performed“. Bereits vor dem 5. November erfasster Verbrauch wird nicht rückwirkend geändert.
Für das Beispiel bedeutet das: Wird ein Vorgang aktualisiert, die Priorität ist aber nicht kritisch und die Regel endet an der Bedingung, werden null Schritte angerechnet. Sendet die Regel dagegen eine Nachricht, zählen die relevanten ausgeführten Schritte. Je nach Ablauf können auch fehlgeschlagene Läufe Verbrauch erzeugen, wenn eine Aktion ausgeführt wurde. Maßgeblich sind die Zählregeln von Atlassian.
Modulare Regeln müssen deshalb nicht allein wegen aktionsloser Prüfungen neu gebaut werden. Bei Läufen mit Aktionen bleiben Anzahl und Platzierung tatsächlich ausgeführter Schritte relevant. In Schleifen zählen ausgeführte innere Aktionen pro Durchlauf; einige Systemschritte wie Log-Aktionen sind ausgenommen.
Mehr Transparenz ab Dezember
Organisationsadmins finden den Gesamtverbrauch in Atlassian Administration unter Usage → Meters → Automation steps. Dort lässt sich das gemeinsame Kontingent mit dem Verbrauch vergleichen. Für Ursachen reicht dieser Gesamtwert allein nicht: Eine einzelne häufig laufende Regel kann den Ausschlag geben.
Bis Anfang Dezember sollen die Usage-Tabs in Jira, Jira Service Management und Confluence Regeln nach Schrittverbrauch aufschlüsseln. Das Audit-Log soll Schritte je Lauf und je ausgeführtem Schritt zeigen; CSV-Exporte sollen die Schrittzahlen enthalten. Der Regel-Builder zeigt zudem voraussichtlichen Verbrauch vor der Aktivierung. Die Detailansichten sind angekündigt beziehungsweise im Rollout, nicht als überall bereits verfügbar vorauszusetzen.
Was weiterhin zu tun ist
Auch die Verteilung des gemeinsamen Kontingents bleibt eine Governance-Frage: Verbraucht ein Team mehr, steht den anderen entsprechend weniger zur Verfügung. Ein separates Budget je Site ist in der Ankündigung für 2027 noch nicht zugesagt. Legt intern fest, wer Verbrauch prüft und Abweichungen mit den verantwortlichen Teams klärt.
Die Kurskorrektur beseitigt einen Fehlanreiz, aber nicht die Verantwortung für Budget und Betrieb. Das enthaltene Kontingent bleibt unverändert. Für Verbrauch darüber beginnt die Abrechnung am 3. Dezember 2026, bei Enterprise zur Vertragsverlängerung an oder nach diesem Datum.
Pay-as-you-go ist laut Atlassian standardmäßig aktiviert. Organisations- und Abrechnungsadmins können zusätzliche Nutzung begrenzen oder abschalten. Das ist eine Betriebsentscheidung: Läuft zusätzliche Nutzung, können Mehrkosten entstehen; ist sie abgeschaltet und das Kontingent erschöpft, stoppen Automationen bis zum nächsten Reset. Ein Kostenlimit schützt das Budget, kann aber ebenfalls Abläufe unterbrechen. Feingranulare Steuerungsmöglichkeiten für Organisationen sind für 2027 angekündigt; Details stehen noch aus.
- Jetzt unter Usage → Meters das organisationsweite Kontingent, den Verbrauch und die Prognose prüfen. Werte vor und nach dem 5. November getrennt betrachten.
- Mit den Fachverantwortlichen festlegen, welche Automationen kritisch sind und ob zusätzliche Nutzung, ein Limit oder eine Unterbrechung tragbar ist.
- Ab Dezember die verbrauchsstärksten Regeln im Usage-Tab öffnen, Audit-Logs prüfen und erst dann gezielt optimieren. Besonders auf Schleifen und häufige Auslöser achten.
- Den Abrechnungstermin und die Vertragsbedingungen für die eigene Organisation prüfen. KI-Aktionen können separat Rovo Credits verbrauchen.
Kosten sollten planbar sein, ohne Wartbarkeit zu opfern. In unserem Atlassian-Lizenzmanagement betrachten wir deshalb Verbrauchstreiber und Lizenzoptionen zusammen, bevor Regeln verändert werden.
