Optimize Costs with Forge: How Clever Architecture Saves Real Money

Forge has become a central building block for Atlassian Cloud development. Its serverless approach removes significant infrastructure work from teams, enables rapid prototyping, and provides a secure execution environment. However, as comfortable as the platform may seem, developing Forge apps without attention to logging, data models, or API calls quickly risks unnecessary resource wastage – both concerning invocation limits within the Atlassian environment and the costs of external systems being connected.

Especially in organizations running dozens or even hundreds of internal automations, it becomes clear: the architecture determines whether an app operates resource-efficiently or silently consumes quotas and budget. It is time to look at how Forge can be used more efficiently.

Why Cost Optimization Matters

While Forge is serverless, it is not free of resource limits or indirect costs. Every app is subject to Invocation Limits; exceeding these causes invocations to be rejected for the remainder of the rate-limit window, and persistent overuse can lead to app suspension. Every log line lands in a system that, in turn, incurs storage and retention costs. And every external API an app queries generates accesses that may even translate directly into money, depending on the provider.

Many of these costs are not obvious. They emerge gradually – for instance, through increasing log volumes, unnecessarily frequent API calls, or a data model that loads the same information repeatedly with every operation.

A concrete example: a polling-based synchronization running every 5 minutes causes 288 invocations per day – even if data changes only once daily. An event-driven solution would require only 1–2 invocations, saving 99% of executions.

This is precisely why a conscious architectural approach pays off early.

Logging: Less is Often More

Many teams begin by “logging everything just in case” – after all, they want to find errors quickly and trace processes. However, this approach rapidly leads to massive log files, high monitoring effort, and ultimately higher costs.

A more effective strategy involves a lean and structured approach to logs: focus on logging central events, genuine errors, and information immediately required for analysis or support. Repeated status messages, extensive payloads, or purely technical intermediate steps can almost always be omitted. Uniform log formats also pay off – they facilitate analysis and shorten the time developers later spend debugging.

A practical example: reducing a request from 1,000 log lines to 50 targeted logs can save several GB of storage and transfer volume across 10,000 daily requests.

Equally important is Retention: while a few days are often sufficient in development environments, production logs should be deliberately and incrementally retained. Many companies save noticeable monitoring costs through this alone.

Important to Know: Forge provides logging via the Console API (console.log, console.warn, console.error), viewable in the Developer Console and via the forge logs CLI. For external monitoring, Forge offers the App Logs Export API, which exports logs in OTLP (OpenTelemetry) format to tools like Splunk, Datadog, or New Relic. Still, teams should be mindful that excessive log volume increases storage and transfer costs regardless of the export method.

Designing Data Models with Intent

Another cost driver is how data is handled. Forge offers various storage mechanisms – the Key-Value Store for simple data, the Custom Entity Store for structured and queryable data, and Forge SQL for full relational databases. External services can be connected via Forge Remote. Yet, they all generate compute or query overhead. It becomes particularly resource-intensive when large amounts of data are unnecessarily stored, or when every function repeatedly loads the same information from Jira or Confluence.

A lean data model is therefore one of the most effective optimization levers. Often, it is sufficient to store only references or IDs instead of the entire entity data. Caching can also provide relief: if data rarely changes, it does not need to be retrieved again with every function call. Some teams combine Forge Storage with external caching or use mechanisms like ETags on external HTTP APIs to check whether data genuinely needs to be reloaded.

It is especially efficient to batch write operations. Instead of writing to storage with every single action, multiple events can be collected first and then persisted in one step. This reduces invocations, network traffic, and ultimately the resource load.

Architectural Principles with Major Impact

Many of the largest savings potentials stem from choosing the right architecture. Polling-based solutions, for instance, frequently cause enormous invocation numbers and log volumes because they query data at fixed intervals, even when nothing has changed. Event-driven approaches are almost always more efficient: they react only when something actually happens and require significantly fewer executions.

The size of individual functions also affects efficiency and limits. The more compact a process is, the faster it operates and the lower the invocation consumption. Dividing complex processes into smaller, targeted Functions not only increases efficiency but also improves maintainability.

External API calls are another factor often underestimated. Many providers charge per request, and this can be substantial, especially when synchronizing large amounts of data. These costs can be significantly reduced through techniques like delta synchronization, batch processing, or intelligent retry behavior. Idempotent processes also prevent errors or retries from creating duplicate actions – and thus double costs.

Efficient Use of Atlassian Resources

Since Forge is closely integrated with Atlassian products, optimization is possible there too. APIs should only return the data truly needed. Many teams, for example, query complete Issue objects even when only two or three fields are required. This results in higher network load, longer runtimes, and increased invocation costs.

The correct use of pagination is similarly crucial. Large datasets should not be fetched in a few extremely large queries — this burdens the functions and increases the error rate. A controlled, step-by-step loading process is better.

Monitoring with Perspective

Monitoring is indispensable for operations — but here, too, quality over quantity is key. Mirroring all logs to external systems or automatically reporting every small error as an incident generates costs and alert fatigue. A much more efficient approach involves monitoring key functions specifically, defining clear alerts, and forwarding filtered logs.

Uniform Trace IDs further help to locate problems faster without needing to store large volumes of raw data.

Good to know: Forge provides a built-in traceId for each invocation, available in the invocation context and included as trace headers (x-b3-traceid) in Forge Remote requests. The Developer Console supports searching logs by Trace ID. For cross-system tracing beyond the Forge boundary, teams may supplement this with custom correlation IDs.

Good Architecture Doesn’t Just Save Money – It Makes Apps Better

Cost optimization in Forge often sounds like a restriction, but in practice, it is the opposite. It almost always leads to architectures that are faster, more stable, and easier to maintain. Those who deliberately design their apps, use logging sensibly, and process data sparingly not only improve efficiency but also the user experience and the robustness of the entire solution.

Companies that invest early in clear principles benefit long-term: every new app becomes more resource-efficient, more performant, and easier to operate. And that makes Forge exactly what it should be – a platform that facilitates, rather than complicates, innovation.

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. And we can get you unstuck if you’ve started the vibe-coding journey on Forge.