Atlassian's OpenTelemetry Migration Changes Everything

Atlassian's migration of its 100,000-host metrics platform to OpenTelemetry didn't make many headlines outside infrastructure circles. It should have. For Jira admins and platform engineers who rely on Marketplace apps, this kind of internal architectural shift carries real implications — not tomorrow, but within the planning horizon that matters.

What Atlassian Actually Did

OpenTelemetry (OTel) is an open-source observability framework that standardises how telemetry data — metrics, traces, logs — is collected and exported across systems. Atlassian migrated a metrics pipeline covering 100,000 hosts to this standard. That's not a small experiment; it's a commitment to a vendor-neutral observability model at scale.

The significance isn't that Atlassian is now "modern." It's that they're aligning their internal infrastructure to the same standard the rest of the enterprise software industry is converging on. When your platform vendor standardises on OTel, the signals they emit — and eventually expose — become interoperable with your existing observability stack.

Why This Should Interest Jira Admins

On the surface, this looks like a DevOps story. Engineers care about distributed tracing; Jira admins care about uptime and issue fields. But the connection is tighter than it appears.

Jira is increasingly a data platform, not just a ticket tracker. As Atlassian adds AI agents, automation layers, and deeper third-party integrations, the operational behaviour of your Jira instance becomes more opaque. Knowing that issues are slow to load is useful. Knowing why — whether it's a particular automation rule, a Marketplace app making excessive API calls, or an upstream Atlassian service degrading — requires telemetry.

Right now, Jira Cloud admins have limited visibility into the performance internals of their instance. You can see automation execution logs. You can see app request counts in a limited way. But you cannot correlate latency spikes with specific triggers in a systematic, programmable way. The gap between "something is slow" and "here is exactly what caused it" remains wide.

OTel standardisation at the infrastructure layer is a prerequisite for surfacing richer observability signals to tenants — eventually. It doesn't happen automatically or immediately, but platform vendors don't invest in this kind of migration without a downstream rationale.

The Marketplace App Layer Is Still a Blind Spot

Here's where the picture gets complicated. Even if Atlassian eventually exposes OTel-compatible telemetry for core Jira operations, Marketplace apps sit in a partially separate execution context depending on how they're built.

Forge apps run inside Atlassian's own infrastructure. In principle, Atlassian could instrument Forge function invocations using the same OTel pipeline and surface that data. Whether they will — and in what form — is not announced, but the architecture makes it possible.

Connect apps run on vendor infrastructure. The telemetry story there is entirely the vendor's responsibility. An admin has no native way to know whether a Connect app is adding 200ms to every issue load or making 50 API calls where 5 would suffice. The closest proxy is the Jira Cloud performance diagnostics tooling, which gives aggregate signals, not causal traces.

This matters when you're evaluating Marketplace apps for a large instance. Security gets scrutinised carefully — Cloud Fortified, Bug Bounty participation, data residency. Performance gets almost no standardised scrutiny at evaluation time. You install the app, run it for 30 days, and either notice something or don't.

What Good Looks Like for Vendors

The responsible posture for a Marketplace app vendor — particularly one building on Forge, where you're executing inside Atlassian's runtime — is to design for low overhead from the start, not to optimise reactively when a customer complains.

That means:

• Minimal API call surface per user action. Every Jira REST call from a Forge function has latency and contributes to rate-limit headroom. Batch where possible, cache aggressively, don't poll when webhooks suffice.
• Asynchronous processing for non-blocking operations. If an app needs to update related issues when a field changes, that work should happen asynchronously, not in the synchronous path that holds up the UI.
• Instrumentation in your own codebase. Even before Atlassian surfaces OTel data externally, vendors can instrument their Forge functions with internal tracing to catch regressions before they reach customers.

This isn't theoretical. When we build features for Multiple Assignees or Merge Assistant, every listener and panel contributes to the total overhead a Jira user experiences — even if they never open our app directly. An issue view that loads 10 Forge panels is slower than one that loads 3. The aggregate matters.

The Longer Arc

Atlassian migrating to OpenTelemetry internally is a bet that the observability layer of the cloud platform will matter more as Jira becomes more complex. AI agents running inside Jira, automation rules chaining across projects, Marketplace apps with deep data hooks — all of this makes the classic "is it slow?" question much harder to answer without structured telemetry.

For admins, the practical move right now is simpler than waiting for platform-level OTel signals:

• Ask vendors directly how they instrument their Forge apps for performance regressions
• Use Jira's automation execution logs as a proxy for automation-layer overhead
• Track instance performance baseline before and after installing new apps — not just after incidents

The infrastructure decisions Atlassian makes internally eventually shape what's possible for tenants. An OTel-standardised backend is the kind of investment that, three years from now, looks like obvious groundwork for something admins care about deeply: knowing exactly what is making their Jira instance slow.