Jira Cloud Limits ab September 2026: was begrenzt wird und wie Sie Ihre Instanz prüfen
Im September 2026 beginnt Atlassian, acht neue Jira Cloud Limits für die Konfiguration durchzusetzen. Begrenzt wird dabei etwa, wie viele Optionen ein Auswahlfeld enthalten darf oder wie viele Releases sich in einem Projekt ansammeln können. Die Limits gelten in allen Plänen, Standard eingeschlossen.
Die meisten Instanzen werden die meisten dieser Grenzen erreichen, ohne dass jemand etwas tun muss. Die Arbeit, die sich lohnt, besteht darin herauszufinden, welchen Grenzen Sie nahe kommen. Diese Prüfung kostet einen Nachmittag.
Die acht neuen Jira Cloud Limits
| Was begrenzt wird | Limit | Geltungsbereich |
|---|---|---|
| Feldoptionen | 20.000 | pro Feld |
| Releases (Versionen) | 15.000 | pro Space |
| Komponenten | 10.000 | pro Space |
| Status | 200 | pro Workflow |
| Workflows | 150 | pro Workflow-Schema |
| Prioritäten | 100 | pro Space |
| Berechtigungszuweisungen | 50 | pro Berechtigung |
| Sicherheitsstufen für Work Items | 50 | pro Space |
Zwei dieser Angaben werden regelmäßig mit dem falschen Geltungsbereich zitiert, auch in Atlassians eigenem Ankündigungsbeitrag. Workflows sind pro Workflow-Schema begrenzt, nicht pro Site: 400 Workflows in der gesamten Instanz sind unproblematisch, 151 in einem einzigen Schema nicht. Status sind pro Workflow begrenzt, Ihre globale Statusliste darf also deutlich länger als 200 Einträge sein.
Zur Terminologie: Atlassian schreibt inzwischen Space, wo die meisten Admins weiterhin Projekt sagen, und Work Item statt Vorgang.
Was sich bereits im März 2026 geändert hat
September ist die zweite Welle. Die erste gilt seit März 2026 und begrenzt Felder auf 700 pro Space und Work-Item-Typen auf 150 pro Space. Die Feldzahl wird über die Feldkonfigurationsschemata ermittelt, Felder im Papierkorb zählen nicht mit. Liegt ein Space bereits über einem der beiden Werte, können Sie ihm keine weiteren Felder oder Work-Item-Typen zuordnen, bis die Zahl wieder sinkt.
Limits und Guardrails sind nicht dasselbe
Atlassian veröffentlicht beides, und der Unterschied ist wichtig. Limits werden technisch erzwungen. Guardrails sind empfohlene Obergrenzen, deren Überschreitung niemand verhindert, ab denen Atlassian aber keine Performance mehr zusichert.
Die aktuellen Guardrails: 18.000.000 Work Items und 8.400 Spaces pro Site, 5.000 Rollenzuweisungen pro Space sowie 2.000 Space-Rollen pro Benutzer und Site. Die ersten beiden Werte sind so hoch, dass Sie bei Annäherung ein architektonisches Problem haben und keine Aufräumaufgabe.
Was beim Erreichen eines Limits passiert
Blockiert wird ausschließlich die Aktion, die das Limit überschreiten würde. Teams legen weiterhin Work Items an, kommentieren und führen Übergänge aus. Gestoppt wird nur der konkrete administrative Vorgang: die 20.001. Option an einem Feld, das 15.001. Release, die 51. Zuweisung auf „Projekte durchsuchen“.
Nichts Bestehendes wird gelöscht. Konfiguration, die zum Stichtag bereits über der Grenze liegt, bleibt erhalten. Sie können lediglich nichts mehr hinzufügen.
Bei einer Migration in die Cloud gelten sechs Monate ab dem Migrationsdatum statt der Frist im September. Das reicht, um die Konfigurationsprüfung in die Migration zu integrieren, statt sie zweimal durchzuführen, und ist damit auch günstiger. Unser Migrationsprogramm (englisch) deckt die App-Seite dieses Umzugs ab.
Der Unterschied zu den Issue-Limits von 2024 und 2025
Wer die früheren Obergrenzen bereits bearbeitet hat, hält das hier womöglich für dieselbe Sache. Es ist ein anderes Problem mit einer anderen Zuständigkeit.
| Work-Item-Limits 2024–2025 | Konfigurationslimits 2026 | |
|---|---|---|
| Was begrenzt wird | Inhalte in einem Work Item: Kommentare, Arbeitszeiten, Anhänge, Verknüpfungen | Konfiguration eines Space, Schemas oder Feldes |
| Woher das Wachstum kommt | Benutzer und Integrationen | Administrative Entscheidungen über Jahre hinweg |
| Am Limit | Überschuss wird in ein verknüpftes Element oder Archiv verschoben | Die administrative Aktion wird blockiert |
| Behebung | Element aufteilen, Prozess ändern | Konfiguration zusammenführen oder löschen |
Die Konfigurationsgrenzen von 2026 und die älteren Jira Cloud Limits pro Work Item gelten gleichzeitig. Für die Element-Ebene finden Sie die Details in unserem Beitrag zu den 10.000 Arbeitszeiten pro Vorgang sowie im ausführlichen Leitfaden zu den Jira Cloud Issue Limits (englisch).
Woher der Druck üblicherweise kommt
Die Vorbereitung gleichmäßig auf alle acht Limits zu verteilen, ist Zeitverschwendung. Bei dreien steckt ein Mechanismus dahinter, der zuverlässig für Wachstum sorgt.
Berechtigungszuweisungen, 50 pro Berechtigung. Der mit Abstand niedrigste Wert der Liste und derjenige, der durch ganz normale Administrationsarbeit wächst. Schemata, die auf einer Gruppe pro Team aufbauen, sind schnell am Ende: Bei fünfzig Teams, denen „Projekte durchsuchen“ jeweils einzeln zugewiesen wurde, ist das Limit für diese eine Berechtigung erreicht. Rollenbasierte Zuweisungen haben dieses Problem nicht, was das Argument für sie ist.
Releases, 15.000 pro Space. Handgepflegte Releaselisten kommen dem nie nahe. Eine CI-Pipeline, die pro Build eine Version anlegt, schon: Bei dreißig Builds pro Tag sind 15.000 nach rund sechzehn Monaten erreicht, und es fällt niemandem auf, weil niemand die Releaseseite liest.
Feldoptionen, 20.000 pro Feld. Ein manuell gepflegtes Auswahlfeld kommt dort nicht hin. Eines, das aus einem Fremdsystem befüllt wird, unter Umständen schon. Kundenlisten, Kostenstellen und Anlagenverzeichnisse sind die üblichen Kandidaten.
Von den übrigen sind Status pro Workflow und Workflows pro Schema selten, aber unangenehm, wenn sie eintreten: Betroffen ist dann das eine große gemeinsame Schema, von dem die halbe Organisation abhängt. Sicherheitsstufen sind nur relevant, wenn Sie Work-Item-Sicherheit überhaupt einsetzen, und Instanzen, die das tun, legen gern eine Stufe pro Kunde an. Komponenten und Prioritäten zählen Sie einmal und können sie danach vergessen.
Die eigene Instanz zählen
Der Site Optimizer zeigt genau das innerhalb von Jira, gehört aber zu Premium und Enterprise. Unter Standard bekommen Sie jede dieser Zahlen trotzdem über die öffentliche REST-API.
| Limit | Wo Sie zählen |
|---|---|
| Feldoptionen | GET /rest/api/3/field, danach GET /rest/api/3/field/{fieldId}/context/{contextId}/option je Kontext |
| Releases | GET /rest/api/3/project/{projectIdOrKey}/version |
| Komponenten | GET /rest/api/3/project/{projectIdOrKey}/component |
| Prioritäten | GET /rest/api/3/priority/search |
| Berechtigungszuweisungen | GET /rest/api/3/permissionscheme/{schemeId}/permission |
| Sicherheitsstufen | GET /rest/api/3/issuesecurityschemes und /issuesecurityschemes/level |
| Workflows und Status | GET /rest/api/3/workflowscheme sowie die Workflows-API |
| Limits pro Element | GET /rest/api/3/issue/limit/report |
Zwei Dinge sollten Sie dabei beachten. Zählen Sie in dem Geltungsbereich, den das Limit verwendet: Der häufigste Fehler besteht darin, Berechtigungszuweisungen pro Schema zu summieren, eine komfortable Zahl zu sehen und weiterzugehen, obwohl die Grenze bei 50 Zuweisungen auf einer einzelnen Berechtigung liegt. Und die paginierten Endpunkte liefern bereits in der ersten Antwort ein total, Sie müssen für die Zählung also nicht durch alle Seiten blättern.
Notieren Sie die Zahlen mit Datum. Eine Messung sagt Ihnen, ob Sie darüber liegen. Zwei sagen Ihnen, wann Sie darüber liegen werden, und bei den drei genannten Limits ist das die nützlichere Antwort.
Die Aufräum-Werkzeuge
Atlassian hat zusammen mit den Limits auch Werkzeuge zur Bereinigung ausgeliefert, und zwar nicht nur für Premium. Sie können ungenutzte Optionen benutzerdefinierter Felder per Massenaktion deaktivieren, ungenutzte Sicherheitsstufen löschen sowie ungenutzte Gruppen und gesperrte Benutzer aus Berechtigungszuweisungen entfernen.
Führen Sie das Letzte zuerst aus. In einer über Jahre gewachsenen Instanz verweist ein guter Teil der Berechtigungszuweisungen auf Gruppen ohne Mitglieder oder auf längst ausgeschiedene Personen. Damit ist das engste Limit der Liste zugleich häufig dasjenige, das sich am günstigsten wieder unterschreiten lässt.
Aus der Messung eine Routine machen
Ein Skript beantwortet die Frage einmal und nur für die Person, die es ausgeführt hat. Die Frage kommt jedes Quartal zurück.
Als die Limits pro Vorgang 2024 eingeführt wurden, haben wir genau das als Report Builder-Bericht auf Basis der Issue-Limit-Report-API gebaut: ein Dashboard-Gadget, das jedes Limit grün, gelb oder rot anzeigt, mit direktem Absprung zu den betroffenen Vorgängen.
Für die Konfigurationslimits braucht es andere Aufrufe, aber denselben Berichtstyp. Report Builder kann die oben genannten Endpunkte planmäßig abfragen, jeden Wert gegen das veröffentlichte Limit stellen und das Ergebnis auf einem Dashboard darstellen, inklusive der Veränderung zum Vormonat. Wenn Sie den Bericht lieber fertig hätten, als ihn selbst zu bauen: vereinbaren Sie eine Demo, wir gehen ihn gemeinsam durch.
Vor September
Zählen Sie einmal alles, über sämtliche Spaces und Schemata hinweg. Ein halber Tag Skriptarbeit erledigt entweder das Thema oder zeigt Ihnen genau, wo Sie hinschauen müssen.
Alles, was über 80 Prozent eines Limits liegt, bekommt eine zuständige Person und ein Datum. Beginnen Sie mit den Berechtigungszuweisungen.
Suchen Sie anschließend, was das Wachstum erzeugt. Eine Bereinigung, die die Pipeline mit ihrer Version pro Build unangetastet lässt, verschafft Ihnen Monate, keine Jahre.
Wiederholen Sie die Zählung Anfang September, damit Sie einen Messpunkt vor und einen nach dem Stichtag haben, und behalten Sie sie danach bei.
Häufige Fragen
Gelten die Limits auch für Standard? Ja, für alle Pläne der Jira-Cloud-Familie und auch für Atlassian Government Cloud. Unterschiedlich ist nur das Werkzeug: Der Site Optimizer bleibt Premium und Enterprise vorbehalten.
Was passiert mit Konfiguration, die bereits über einem Limit liegt? Sie bleibt bestehen. Nichts wird gelöscht, Benutzer merken nichts davon. Sie können lediglich nichts mehr hinzufügen, bis die Zahl sinkt.
Sind das die Kommentar- und Arbeitszeitlimits? Nein. Jene begrenzen Inhalte innerhalb eines einzelnen Work Items und gelten bereits seit 2024. Diese hier begrenzen Konfiguration.
Quellen
- Data limits and guardrails, Atlassian Support
- Growing our investment in a faster, cleaner Jira, Atlassian Community
- Jira Cloud platform REST API
Unverbindlich