Wer zum ersten Mal eine Forge-App entwickelt, liest die Atlassian-Dokumentation, nickt beim Abschnitt über Limits und denkt: Wird schon passen. Und meistens passt es auch – bis es das plötzlich nicht mehr tut. Ein Webhook-Trigger, der bei hohem Ticket-Volumen ins Stocken gerät; ein Panel, das beim Laden einfach zu lange braucht; ein Speicherkonzept, das für die ersten hundert Einträge wunderbar funktioniert und dann leise kollabiert.
Dieser Artikel soll die Lücke zwischen Dokumentation und Realität schließen. Dazu braucht es keine Neuauflage der offiziellen Limits-Liste, sondern einen offenen Blick darauf, wann diese Limits im echten Projektbetrieb spürbar werden – und was Sie architektonisch dagegen tun können.
Die Limits, die wirklich zählen
Nicht alle Forge-Limits sind im Alltag gleichermaßen relevant. Manche werden kaum erreicht; andere begegnen dem Team früher als erwartet. Wer sich auf die folgenden fünf konzentriert, ist gut vorbereitet.
Ausführungszeit, der Klassiker. Synchrone Funktionen operieren in einem engen Zeitfenster. Web-Trigger haben 55 Sekunden; UI-Komponenten (Resolver) teilen sich dasselbe 25-Sekunden-Invocation-Limit. In der Praxis – und vor allem bei Forge Remote – gilt die harte 5-Sekunden-Grenze für Remote-Event-Endpunkte. Was dennoch nach viel klingt, ist bei kaskadierenden Prozessen (Jira → Forge → externe API → Logik → Jira) extrem schnell aufgebraucht. Jede Millisekunde Latenz der externen API zahlt hier direkt auf das Forge-Konto ein.
Forge Storage. Klingt verlockend einfach: Kein externes Datenbank-Setup, sondern einfach Daten ablegen. Das funktioniert hervorragend für Konfigurationswerte oder kleine Lookup-Tabellen. Ein kritischer Punkt im Hinblick auf „Storage als Mini-Datenbank” ist das Limit von 240 KiB pro Value. Wer versucht, große JSON-Arrays in einem einzigen Key zu speichern, rennt sehr schnell gegen eine Wand.
Externe Aufrufe. Sie unterliegen strikten Regeln: Nur explizit erlaubte Domains, begrenzte parallele Fetch-Aufrufe – und Rate Limits externer APIs kommen noch obendrauf.
Die Event Queue. Sie ist das Herzstück asynchroner Verarbeitung – und gleichzeitig eine Quelle stiller Probleme. Bei hohem Durchsatz kann es zu Verzögerungen kommen. Wer zeitkritische Prozesse asynchron abbildet, sollte dieses Verhalten kennen.
UI-Kit-Performance. Wird oft unterschätzt. Komplexe Komponenten oder umfangreiche Datenladungen beim Rendern führen dazu, dass sich eine App einfach träge anfühlt – auch ohne dass ein technischer Timeout greift.
Vier Szenarien, in denen es eng wird
Kommen wir zu ein paar konkreten Beispielen. Die folgenden Szenarien sind nicht konstruiert; sie spiegeln Situationen wider, die in realen Forge-Projekten immer wieder auftauchen.
Szenario 1: Webhook-Trigger bei hohem Ticket-Volumen
Eine App soll bei jeder Aktualisierung eines Jira-Issues Daten in ein CRM synchronisieren. Im Test läuft alles glatt. Im produktiven Betrieb stauen sich plötzlich die Events in der Queue. Ein technischer „Silent Killer” ist hier das Payload-Limit für asynchrone Events: maximal 200 KB kombiniert über bis zu 50 Events pro Push-Request. Wer versucht, das komplette Jira-Issue-Objekt per Event zu übergeben, scheitert oft schon beim Absenden. Die App tut scheinbar einfach nichts, ohne dass ein klassischer Code-Fehler vorliegt. Das Problem liegt selten am Code, sondern daran, dass das Design für ruhige Verhältnisse gebaut wurde – nicht für Spitzenlast.
Szenario 2: Synchrone Aggregation in einem Panel
Ein Issue Panel soll sofort eine Zusammenfassung liefern: verknüpfte Tickets, Statusverteilung, Kommentare. Nutzt man UI Kit, wird die Logik serverseitig in einer Lambda-Funktion ausgeführt. Jeder Klick bedeutet einen Roundtrip zur Cloud. UI-Resolver teilen das standard 25-Sekunden-Invocation-Limit, kaskadierende API-Aufrufe führen also selten zu einem harten Timeout – aber die gefühlte Performance sinkt ab 5 Sekunden massiv. Diese 5-Sekunden-Marke ist eine UX-Faustregel, kein technisches Plattform-Limit. Nutzer erleben das nicht als Fehler, sondern als langsame App. Das ist in der Praxis oft schlimmer.
Szenario 3: Forge Storage als Mini-Datenbank
Was als pragmatische Lösung beginnt, entwickelt sich zum Konstrukt, das den Storage überfordert. Wenn Schlüssel-Wert-Paare als Ersatz für relationale Daten herhalten, Listen manuell paginiert werden und Schreibkonflikte auftreten, muss das Datenmodell überdacht werden. Storage ist kein Datenbankersatz.
Szenario 4: Viele externe Abhängigkeiten
Apps, die mit Identity-Providern, Ticketsystemen und internen APIs kommunizieren, kämpfen mit der Summe aller Latenzen. Wenn ein externer Service langsam antwortet, zieht das die gesamte Forge-Ausführungszeit in Richtung des 55-Sekunden-Limits bei Web-Triggern bzw. des 25-Sekunden-Limits bei Resolvern. Hier rächt sich fehlende Planung in der Architekturphase besonders schnell.
Was Ihr Team dagegen tun kann
Für die meisten dieser Situationen gibt es bewährte Lösungsansätze. Sie erfordern kein Umschreiben der gesamten App, aber oft ein Umdenken im Hinblick auf die Architektur.
Async statt sync, wo immer möglich. Alles, was nicht unmittelbar ein Ergebnis für den Nutzer braucht, gehört in einen asynchronen Pfad. Aber Achtung: Ein einzelner Push-Request kann maximal 50 Events mit einem kombinierten Payload von 200 KB enthalten. Die Consumer-Concurrency ist konfigurierbar und per Default unbegrenzt – bei anhaltend hoher Last kann es trotzdem zu Queue-Verzögerungen kommen.
Chunking und Paginierung von Anfang an einplanen. Große Datenmengen sollten nie als Ganzes verarbeitet werden. Wer von Beginn an in Batches denkt, vermeidet die meisten Queue- und Timeout-Probleme – und baut gleichzeitig robusteren Code.
Storage für das nutzen, wofür es gedacht ist. Konfigurationswerte, Feature-Flags, einfache Nutzereinstellungen – das ist der Sweet Spot. Sobald die Datenstruktur komplexer wird oder häufige Updates nötig sind, lohnt sich die Überlegung, ob ein externer Speicher (über eine eigene API angebunden) die bessere Wahl ist.
Caching mit klarem Verfallsdatum. Daten, die sich selten ändern, müssen nicht bei jedem Aufruf neu geladen werden. Ein durchdachtes Caching-Konzept entlastet sowohl die Ausführungszeit als auch externe APIs – solange das Team dabei konsequent definiert, wann ein Cache-Eintrag als veraltet gilt.
UI Kit vs. Custom UI. Wer komplexe Datenmengen visualisiert, sollte auf Custom UI setzen. Da statische Assets im Browser laufen, wird das serverseitige Zeitkonto entlastet. Zudem ermöglicht Custom UI asynchrones Nachladen (z. B. via Shimmer-Effekt). Das Ziel: Die UI steht in unter 5 Sekunden, auch wenn die Daten noch laden.
Forge als Orchestrator, nicht als Prozessor. Bei rechenintensiven oder zeitaufwändigen Aufgaben kann es sinnvoll sein, Forge nur die Koordination übernehmen zu lassen, während die eigentliche Verarbeitung an einen externen Service delegiert wird. Das verschiebt Komplexität, löst sie aber manchmal eleganter als jede interne Optimierung.
Wann Limits ein Warnsignal sind
Es gibt eine unbequeme Wahrheit, die in diesem Kontext nicht fehlen sollte: Ein Team, das sich dauerhaft an den Grenzen von Forge bewegt und ständig gegen Limits ankämpft, sollte innehalten und fragen, ob das Problem an der Implementierung liegt – oder am gewählten Ansatz. Forge ist für ein klar umrissenes Einsatzgebiet gebaut: sichere, cloud-native Erweiterungen des Atlassian-Ökosystems. Es ist kein General-Purpose-Backend.
Bei hohen Durchsatz-Anforderungen ist man mit einer eigenen Backend-Infrastruktur besser bedient, wobei Forge nur noch als Integrationsschicht dient. Das ist keine Kritik an Forge, sondern ein Plädoyer für das richtige Werkzeug an der richtigen Stelle. Forge Remote kann so ein Werkzeug sein.
Forge Remote als „Escape Hatch” für komplexe Logik
Wenn Timeouts oder Speicherengpässe immer wieder zum Flaschenhals werden, bietet Forge Remote einen Ausweg. Die aktuelle Forge-Runtime stellt bis zu 1024 MB RAM bereit (512 MB als Standard) – das 128-MB-Limit galt nur für die Legacy-Runtime und ist für aktuelle Deployments nicht mehr relevant. Die Logik und Datenbanken laufen auf Ihrer Infrastruktur (AWS, Azure, etc.). Sie behalten die volle Kontrolle und können Bibliotheken nutzen, die in der Forge-Sandbox Probleme bereiten.
Aber Achtung: Forge Remote entbindet Sie nicht von allen Limits. Für Remote-Aufrufe gelten eigene „Contracts”. So müssen Remote-Endpunkte bei Events oft innerhalb von 5 Sekunden antworten. Forge Remote verschiebt die Komplexität also eher von der Laufzeit-Beschränkung hin zur Infrastruktur-Verantwortung – Security, Latenz und Skalierung liegen dann in Ihrer Hand.
Forge-Limits verstehen
Forge-Limits sind keine willkürlichen Hindernisse. Sie spiegeln das Designprinzip einer sicheren, skalierbaren Plattform wider. Ein Team, das sie kennt und von Anfang an in die Architektur einbezieht, wird selten überrascht. Ein Team, das sie ignoriert, baut auf Sand.
Die wichtigste Lektion aus der Praxis lautet: Limits werden selten zum Problem, wenn man mit ihnen plant. Sie werden zur Herausforderung, wenn man so tut, als gäbe es sie nicht – oder die kritische 5-Sekunden-Marke für die User Experience ignoriert.
Plant Ihr Team einen Wechsel zu Forge oder möchten Sie Ihre App-Strategie modernisieren? Unsere erfahrenen Atlassian-Entwicklungsteams unterstützen Sie bei Architektur, Entwicklung und Zertifizierung. Melden Sie sich per E-Mail oder vereinbaren Sie direkt einen Remote-Termin mit uns!