Jira Cloud: Neue Limits ab September 2026

Atlassian führt ab September 2026 schrittweise zusätzliche Konfigurations-Limits für Jira Cloud ein. Die neuen Grenzwerte betreffen unter anderem Feldoptionen, Sicherheitsstufen, Berechtigungen, Releases, Workflows, Komponenten und Prioritäten.

Für Unternehmen mit umfangreichen Jira-Instanzen bedeutet das: Bestehende Konfigurationen bleiben erhalten, neue Elemente können jedoch blockiert werden, sobald ein Limit erreicht ist. Jira-Administratoren sollten ihre Nutzung deshalb frühzeitig prüfen und nicht mehr benötigte Konfigurationen bereinigen.

Limits und Guardrails im Vergleich

Was ist ein Limit?

Ein Limit ist eine Software-seitig erzwungene Obergrenze für eine bestimmte Daten- oder Konfigurationsart.

Wenn das Limit erreicht ist, verhindert Jira eine administrative Aktion, durch die weitere Elemente dieser Art hinzugefügt würden. Bereits vorhandene Konfigurationen bleiben verfügbar und funktionieren weiterhin.

Was ist ein Guardrail?

Ein Guardrail ist ein empfohlener Richtwert für eine überschaubare und leistungsfähige Jira-Konfiguration. Guardrails werden nicht technisch erzwungen.

Eine Überschreitung blockiert daher nicht automatisch weitere Aktionen. Sie kann jedoch die Komplexität erhöhen und sich – abhängig von Abfragen, Datenmenge, Zugriffsmustern, Apps und Integrationen – negativ auf die Performance auswirken.

Welche Jira-Limits gelten ab September 2026?

Ab September 2026 beginnt Atlassian mit der schrittweisen Durchsetzung der folgenden zusätzlichen Limits. Da der Rollout progressiv erfolgt, kann der konkrete Aktivierungszeitpunkt je nach Entität oder Jira-Instanz variieren.

Die Limits gelten für die Jira-Cloud-Produktfamilie, einschließlich Jira, Jira Service Management und Jira Product Discovery, sofern die jeweilige Funktion im Produkt verfügbar ist.

Was bedeuten die einzelnen Grenzwerte?

Feldoptionen

Pro Feld dürfen maximal 20.000 Optionen konfiguriert werden. Sobald dieser Wert erreicht ist, können Administratoren keine weiteren Optionen für das betreffende Feld anlegen. Bereits vorhandene Optionen bleiben verfügbar.

Sicherheitsstufen

Ein Space darf maximal 50 Sicherheitsstufen für Vorgänge enthalten. Bestehende Sicherheitsstufen und Vorgänge, die diese Sicherheitsstufen verwenden, bleiben funktionsfähig.

Berechtigungszuweisungen

Pro Berechtigung sind maximal 50 Zuweisungen möglich. Eine Zuweisung kann beispielsweise einem Benutzer, einer Gruppe oder einer Space-Rolle ein bestimmtes Recht erteilen.

Releases und Versionen

Sobald ein Space das Limit von 15.000 Releases erreicht, können keine weiteren Releases angelegt werden. Archivierte Releases sollen bei der Ermittlung dieses Limits nicht berücksichtigt werden. Bestehende Releases und die damit verbundenen Vorgänge bleiben verfügbar.

Workflows und Status

Ein Workflow-Schema darf maximal 150 Workflows enthalten. Ein einzelner Workflow darf maximal 200 Status umfassen.

Das Erreichen eines Limits beeinträchtigt die bestehenden Workflows nicht. Administratoren können jedoch keine weiteren Workflows oder Status hinzufügen, solange die betroffene Konfiguration nicht bereinigt wurde.

Komponenten

Pro Space sind maximal 10.000 Jira-Komponenten zulässig. Dieses Limit betrifft Jira-Komponenten und nicht Compass-Komponenten.

Prioritäten

Eine Prioritätskonfiguration darf maximal 100 Prioritäten für den betroffenen Space enthalten. Bestehende Prioritäten und Vorgänge, die diese verwenden, bleiben erhalten.

Welche Guardrails empfiehlt Atlassian?

Zusätzlich zu den festen Limits nennt Atlassian folgende empfohlene Richtwerte:

Diese Werte sind keine harten Obergrenzen. Sie dienen dazu, die Datenstruktur einer großen Jira-Instanz überschaubar zu halten.

Was passiert beim Erreichen eines Limits?

Wenn eine Konfiguration bereits am Limit liegt oder darüber liegt, lehnt Jira eine administrative Aktion ab, durch die weitere Elemente hinzugefügt würden. Eine Sammelaktion wird dabei abgelehnt, wenn sie die Konfiguration über das zulässige Limit hinaus erweitern würde. Jira wendet die Aktion nicht teilweise an.

Für Endanwender hat das Erreichen eines Limits in der Regel keine unmittelbaren Auswirkungen:

• Bestehende Konfigurationen bleiben verfügbar.
• Jira löscht, archiviert, deaktiviert oder verändert keine bestehenden Daten automatisch.
• Benutzer können weiterhin Vorgänge erstellen und aktualisieren.
• Administratoren können unabhängige Konfigurationsänderungen durchführen.
• Andere Konfigurationen, die unterhalb ihres jeweiligen Limits liegen, bleiben unverändert.
• Jira zeigt eine Meldung an, wenn eine administrative Aktion wegen eines Limits abgelehnt wird.

Wie können Unternehmen ihre Jira-Instanz vorbereiten?

Jira-Administratoren sollten vor dem vollständigen Rollout der Limits eine Bestandsaufnahme durchführen. Besonders relevant sind Instanzen mit vielen Projekten, komplexen Berechtigungsschemata, historisch gewachsenen Workflows oder zahlreichen Marketplace Apps.

1. Konfigurationen und Nutzung prüfen

Prüfen Sie insbesondere:

• Feldoptionen mit vielen veralteten oder doppelten Einträgen
• Nicht mehr verwendete Sicherheitsstufen
• Überflüssige Berechtigungszuweisungen
• Alte oder archivierte Releases
• Nicht mehr benötigte Workflows und Workflow-Status
• Veraltete Komponenten
• Nicht verwendete Prioritäten
• Space-Rollen und Rollenmitglieder oberhalb der empfohlenen Guardrails
  
  

Beispiele für die Prüfung Ihrer Konfiguration:

Prüfen und Löschen nicht benutzter Sicherheitsstufen

2. Nicht benötigte Konfigurationen bereinigen

Entfernen Sie veraltete Elemente nicht pauschal. Vor der Bereinigung sollte geprüft werden, ob sie noch in Vorgängen, Workflows, Filtern, Automatisierungen, Reports oder Integrationen verwendet werden.

Besonders wichtig ist eine Abhängigkeitsprüfung bei:

• Benutzerdefinierten Feldern
• JQL-Filtern
• Automatisierungen
• Berechtigungsschemata
• Workflow-Übergängen
• Externen Integrationen

Beispielhaft für ungenutzte Feldoptionen:

Beispielhaft für das Bereinigung von Berechtigungszuweisungen:

3. Site Optimizer verwenden

Kunden mit Enterprise- und Premium-Tarifen können den Site Optimizer nutzen, um die Datennutzung zu analysieren und nicht verwendete Entitäten zu identifizieren. Je nach Konfiguration lassen sich beispielsweise ungenutzte Feldoptionen, Sicherheitsstufen oder überflüssige Berechtigungszuweisungen bereinigen.

Standard-Kunden können die Nutzung in den Jira-Einstellungen prüfen. Für umfangreichere Audits eignen sich außerdem REST APIs oder eigene Skripte.

4. Performance-Faktoren ganzheitlich betrachten

Die neuen Limits sind nicht der einzige Faktor für die Performance einer großen Jira-Instanz. Relevant sind unter anderem:

• Umfang und Komplexität von JQL-Abfragen
• Konfiguration von Boards und Backlogs
• Anzahl und Verwendung benutzerdefinierter Felder
• Traffic- und Zugriffsmuster
• Automatisierungen
• Marketplace- und eigene Apps
• Integrationen mit anderen Systemen

Eine Reduzierung der Konfiguration kann daher sinnvoll sein, selbst wenn eine Instanz noch unterhalb eines harten Limits liegt.

Fazit

Die neuen Jira-Cloud-Limits ab September 2026 sollen große Instanzen stabiler, zuverlässiger und besser skalierbar machen. Sie führen nicht dazu, dass bestehende Konfigurationen automatisch gelöscht oder deaktiviert werden.

Für Unternehmen entsteht der wichtigste Handlungsbedarf bei administrativen Änderungen: Sobald ein Grenzwert erreicht ist, lassen sich keine weiteren Elemente derselben Kategorie hinzufügen. Eine frühzeitige Bestandsaufnahme, die Bereinigung ungenutzter Konfigurationen und die regelmäßige Überwachung der Guardrails helfen dabei, spätere Einschränkungen im Betrieb zu vermeiden.

Wenn Sie hierbei Hilfe benötigen, sprechen Sie uns an. Wir unterstützen Sie gern.