Forge Limits in Practice: What Really Matters – and How to Handle Them Elegantly

Anyone developing a Forge app for the first time reads the Atlassian documentation, nods at the section on limits and thinks: It’ll be fine. And most of the time it is – until suddenly it isn’t. A webhook trigger that starts struggling under high ticket volume; a panel that simply takes too long to load; a storage concept that works beautifully for the first hundred entries and then quietly collapses.

This article aims to close the gap between documentation and reality. What’s needed isn’t a rehash of the official limits list, but an honest look at when these limits actually become noticeable in real-world projects – and what you can do architecturally about them.

The Limits That Really Matter

Not all Forge limits are equally relevant in day-to-day use. Some are rarely reached; others confront teams earlier than expected. Those who focus on the following five are well prepared.

Execution time, the classic one. Synchronous functions operate within a tight time window. Web triggers have 55 seconds; UI components (resolvers) share the same 25-second invocation limit. In practice – and especially with Forge Remote – the hard 5-second boundary applies to remote event endpoints. What still sounds like a lot is consumed extremely quickly in cascading processes (Jira → Forge → external API → logic → Jira). Every millisecond of latency from an external API is charged directly to your Forge account.

Forge Storage. Sounds deceptively simple: no external database setup, just store your data. This works excellently for configuration values or small lookup tables. A critical point when treating storage as a mini-database is the 240 KiB per value limit. Anyone trying to store large JSON arrays in a single key will hit a wall very quickly.

External calls. These are subject to strict rules: only explicitly allowed domains, limited parallel fetch calls – and rate limits from external APIs add another layer on top.

The Event Queue. It’s the heart of asynchronous processing – and simultaneously a source of silent problems. Under high throughput, delays can occur. Anyone mapping time-critical processes asynchronously should understand this behaviour.

UI Kit performance. Often underestimated. Complex components or extensive data loading during rendering cause an app to simply feel sluggish, even without a technical timeout being triggered.

Four Scenarios Where Things Get Tight

Let’s look at some concrete examples. The following scenarios aren’t contrived; they reflect situations that arise repeatedly in real Forge projects.

Scenario 1: Webhook trigger under high ticket volume

An app should synchronise data to a CRM on every Jira issue update. Everything runs smoothly in testing. In production, events suddenly start piling up in the queue. A technical “silent killer” here is the async event payload limit: up to 200 KB combined across a maximum of 50 events per push request. Anyone trying to pass the complete Jira issue object via an event often fails at the point of sending. The app simply appears to do nothing, without any classic code error being present. The problem rarely lies in the code, but in a design built for calm conditions rather than peak load.

Scenario 2: Synchronous aggregation in a panel

An issue panel should immediately deliver a summary: linked tickets, status distribution, comments. Using UI Kit, the logic runs server-side in a Lambda function. Every click means a roundtrip to the cloud. Since UI resolvers share the standard 25-second invocation limit, cascading API calls rarely cause hard timeouts – but perceived performance drops sharply beyond 5 seconds, which is a UX threshold, not a platform limit. Users don’t experience this as an error – they experience it as a slow app. In practice, that’s often worse.

Scenario 3: Forge Storage as a mini-database

What starts as a pragmatic solution evolves into a construct that overwhelms Storage. When key-value pairs serve as a substitute for relational data, lists are manually paginated, and write conflicts occur, the data model needs rethinking. Storage is not a database replacement.

Scenario 4: Many external dependencies

Apps communicating with identity providers, ticketing systems, and internal APIs struggle with the sum of all latencies. When an external service responds slowly, it drags the entire Forge execution time towards the 55-second web trigger limit or the 25-second resolver limit. Missing planning during the architecture phase takes its revenge particularly quickly here.

What Your Team Can Do About It

For most of these situations, there are proven approaches. They don’t require rewriting the entire app, but often a rethink of the architecture.

Async instead of sync, wherever possible. Anything that doesn’t immediately need to return a result to the user belongs in an asynchronous path. But be careful: a single push request can contain at most 50 events with a combined payload of 200 KB. Consumer concurrency is configurable and unbounded by default, but under sustained load, queue delays can still occur.

Plan for chunking and pagination from the start. Large datasets should never be processed as a whole. Thinking in batches from the beginning avoids most queue and timeout problems while simultaneously producing more robust code.

Use Storage for what it’s designed for. Configuration values, feature flags, simple user settings – that’s the sweet spot. As soon as the data structure becomes more complex or frequent updates are needed, it’s worth considering whether external storage (connected via a dedicated API) is the better choice.

Caching with a clear expiry. Data that rarely changes doesn’t need to be reloaded on every call. A well-thought-out caching strategy reduces both execution time and external API load – as long as the team consistently defines when a cache entry is considered stale.

UI Kit vs. Custom UI. Anyone visualising complex datasets should use Custom UI. Since static assets run in the browser, the server-side time budget is relieved. Custom UI also enables asynchronous data loading (e.g. via shimmer effects). The goal: the UI is ready within 5 seconds, even if the data is still loading.

Forge as orchestrator, not processor. For computationally intensive or time-consuming tasks, it can make sense to let Forge handle only the coordination, while delegating the actual processing to an external service. This shifts complexity, but sometimes resolves it more elegantly than any internal optimisation.

When Limits Are a Warning Signal

There’s an uncomfortable truth that shouldn’t be missing from this context: a team that permanently operates at the boundaries of Forge and constantly fights against limits should pause and ask whether the problem lies in the implementation or in the chosen approach. Forge is built for a clearly defined use case: secure, cloud-native extensions of the Atlassian ecosystem. It is not a general-purpose backend.

For high-throughput requirements, you’re better served with your own backend infrastructure, with Forge serving only as the integration layer. This isn’t a criticism of Forge – it’s an argument for the right tool in the right place. Forge Remote can be that tool.

Forge Remote as an Escape Hatch for Complex Logic

When timeouts or memory constraints repeatedly become a bottleneck, Forge Remote offers a way out. The current Forge runtime provides up to 1024 MB of RAM (512 MB by default) – the legacy runtime had a 128 MB cap, but that no longer applies to current deployments. The logic and databases run on your own infrastructure (AWS, Azure, etc.). You retain full control and can use libraries that cause problems within the Forge sandbox.

But be aware: Forge Remote doesn’t free you from all limits. Dedicated “contracts” apply to remote calls. For example, remote endpoints often need to respond within 5 seconds for events. Forge Remote therefore shifts complexity from runtime constraints towards infrastructure responsibility – security, latency, and scaling are then in your hands.

Understanding Forge Limits

Forge limits are not arbitrary obstacles. They reflect the design principle of a secure, scalable platform. A team that understands them and incorporates them into architecture from the start will rarely be caught off guard. A team that ignores them is building on sand.

The most important lesson from practice: limits rarely become a problem when you plan with them in mind. They become a challenge when you act as if they don’t exist – or ignore the critical 5-second threshold for user experience.

Is your team planning a move to Forge? Do you want to modernize your app strategy? Our experienced Atlassian development teams can support you with architecture, development, and certification. Contact us via email or simply schedule an initial remote meeting with us!