Concerns about immediate enforcement of Analytics Egress Allowlist

Forge
1

This morning we discovered that all our Forge apps can no longer be deployed because we are using Sentry. The related announcement also only appeared this morning, so from what I can see, there was no prior communication. Usually, there is also a grace period for such changes — which is not the case here.

This has a disruptive impact on development workflows, as we cannot deploy updates to our Forge apps without removing Sentry first (or adding it as egress, which would trigger a major update).

The Atlassian developer console, while helpful in some cases, is not comparable to what Sentry (or others) offers developers when it comes to error tracking, debugging, and overall UX.

We may have different views on what counts as analytics, but providing a good developer experience ultimately benefits customers as well.

Could you clarify if Atlassian is planning to provide official tooling or alternatives — for example, a custom Sentry instance or another supported solution — so developers can continue to work with proper error monitoring in Forge apps?

Best regards,
Christopher

24 Likes
2

Hi @chrschommer !

While the RoA team will address the aspects related to analytic tools and comms, I am the product manager for developer console and I would be happy to discuss with you on the gaps/requirements for additional observability next week. Please feel free to schedule some time on my calendar if you prefer a 1:1 direct chat or you could mention the gaps here directly in the post too.

Thanks,

Chandana.

3

Sentry (and other similar tools) provide custom integrations for better observability on the frontend ( @sentry/react - npm ) this is particularly useful if you use state management solutions like redux because you can easily analyse the current application state in case of an error. Logging this to the backend would a) be a considerable effort in re-engineering existing code and b) would incur costs because console logs are not free. additionally the size of the payload is limited so logging an entire application state could not even be possible.

4 Likes
4

Hi Chandana,

Thanks for the quick response and for offering to discuss this further.

To give you a bit more detail on why tools like Sentry are so valuable to us:

  • Finer control over error reporting – We can decide exactly which events to submit, enrich them with context, and avoid noise, rather than just emitting logs at different levels.

  • Deeper insights into issues – Sentry shows exactly where the error occurred in the source code, captures user actions leading up to the error (breadcrumbs, session replay), and records environment details (OS, browser, device), which are crucial for reproducing issues.

  • Error grouping and regression detection – Similar errors are grouped automatically, and if a previously resolved issue reoccurs, we get alerted. This avoids chasing duplicates and helps track whether fixes actually hold.

  • Framework integrations – Sentry integrates seamlessly with modern frameworks like React (which Atlassian’s own component libraries are built on), making it straightforward to capture errors with full context.

  • Efficient UI & search – The Sentry UI makes it easy to focus on the most important issues while still allowing us to dig into details when needed. The ability to search and filter errors across projects is essential for quickly finding root causes.

  • Notifications and alerts – We can receive immediate alerts (email, chat, etc.) when issues occur, so we can react quickly before they impact more customers.

These features combined make Sentry (and similar platforms) not just a log viewer, but a complete observability and debugging toolset. That’s why simply relying on the current Developer Console isn’t a realistic alternative for us.

It’s also unclear to us what exactly you mean by “gaps.” Are you planning to expand beyond logs into a proper error monitoring/observability solution? If so, it would help to understand what the vision is. If the intent is for developers to rely on logs alone, then unfortunately that won’t meet the debugging and operational needs we (and likely many other marketplace developers) have in practice.

Could you clarify whether Atlassian is considering building or supporting a more complete solution — either an official Sentry integration, an in-house alternative, or another supported tool?

best regards

7 Likes
5

There are two issues here that @chrschommer pointed towards:

  • Forge Developer Console still lacks major features for app observability (addressed above).
  • An update was made without any grace period that prevented many partners from deploying their apps to production.

Could Atlassian please also respond on the latter point, which IMHO should be avoided at all costs in the future? I can understand a change like that if a critical security vulnerability needs to be fixed, but given that non-whitelisted analytics egress domains can continue to be used for another 4 weeks, it doesn’t seem to be the case here.

11 Likes
6

From a vendor perspective, the narrowing of the definition of “analytics” to exclude developer observability is a step backwards, and the discussion should be larger than just the RoA program. Even non-RoA apps may want to flag endpoints as “analytics” to easily expose this information to the customer, and to provide the customer with a nice visible switch to be able to turn it all off.

I believe the customer’s primary care is whether or not limited metadata is being egressed and whether or not it is PII; I imagine that only a very tiny subset of customers truly care about whether the data is “analytics” or “observability”.

Customers who are truly paranoid about egress have already turned off all of their optional analytics egress anyway! This leaves Atlassian deciding to neuter a feature based on a presumed set of customers who are apparently loose enough to have no qualms about analytics going out, but who have an apparent problem with observability data.

Also, the new policy describes various services that are specifically excluded because they provide session recording capability. I see that Mixpanel and Userpilot are on the “approved” list, yet they both also support session recording. Will Atlassian be revising the policy to remove these as supported solutions?

Furthermore, if one of the other supported services decides at a later date to introduce a session-recording feature, will they be subject to immediate removal? This would be a slippery slope and I am hoping that Atlassian can clarify this policy now, since it is hard to design a product around constantly-moving goalposts.

We depend on Sentry for running our business. It often allows us to detect Atlassian’s outages faster than Atlassian does. Even if the developer console were somehow made to support all of the same features, under the “don’t run your statuspage on the same infra as your app” mantra, I would still rather have it running elsewhere.

Absent some sort of stability here, I guess we will have to revise the plans (again) to go back to what we were doing with Connect: declare Sentry as an egress and ship a control in our app UI that (if customers can actually find it) allows them to turn it off. Everyone is worse off with this solution.

My constructive criticism is thus: please allow developers to continue to use developer observability tools as analytics egress. If you think there are enough customers who truly care about the difference between “analytics” and “observability”, then why not build a new egress category for it and let the customer decide?

11 Likes
7

Assuming Atalssian is not going to change direction on analytics tools, I’d love to connect to request some bare minimum improvements needed for Forge Developer Console.

At the end of the day, the forge developer console will never be as powerful as APM tools since they have entire companies building them, but given the constraints, we hope that prioritization of observation functionality in dev console could help shorten the current gap.

Specifically:

  1. Better log console: the current one is not easy to use, does not support structured logging (i always have to download a file and then painfully scroll through .log file), the load more is not usable, alerts on logs does not exist (volume, level or keyword/event type).
  2. Error log / exception aggregation. Similar to Rollbar, or Sentry’s Issues - we need to aggregation and traces/context of exceptional events (either errors or console.error) so dev teams can quickly respond to any unexpected errors.
  3. Performance Monitoring. Beyond the abstract “invocation counts/etc”, there really isn’t any way for me to monitor performance or errors on specific custom UI modules, or backend functions, validators, queues, queue consumers, etc. We need both more infrastructure monitoring plus function/module monitoring.
1 Like
8

Whoever wrote this analytics tool policy clearly isn’t a developer and has never had to debug a support issue.

Analytics tools are essential for understanding product usage and improving user experience.

You know what’s also essential for improving user experience: being able to identify and fix bugs.

Also this is yet another Atlassian change that would force apps to undergo yet another major version update - which of course most admins do not action.

So the ratcheting death spiral of app versioning continues. Tick tock.

1 Like
9

You can bet that Atlassian are not using forge developer console to debug their client side code/support issues.

What do they use which they do not permit others to use???

2 Likes
10

No joke, they use sentry.io. Which is ironic and possibly why sentry.io is called out specifically (as opposed to NR, signalfx, Ad/splunk or DD, etc)

11

We chose statsig explicitly because Atlassian uses it and we wanted to limit egress to fewer net new destinations for customers. We asked over and over for this list and were told it’s fine to pick something and Atlassian would be reasonable. Here we are again with having to redo work as if it’s a virtue of Forge to waste our teams time. Atlassian, shame on you.

1 Like
12

Thank you everyone for sharing your concerns about the Analytics Tools Policy. I want to clarify that we did not intend to immediately block deployments for apps using Sentry and Segment in the analytics category. We have updated the temporary allowlist, giving app developers an additional four weeks to decide on their next steps. We apologise for any disruption this may have caused.

In the meantime, we have received several requests to include specific tools in the permanent allowlist. We will review these requests individually and respond to each of you within the next week.

1 Like
13

Thank you for your reply!

In the meantime, we have received several requests to include specific tools in the permanent allowlist. We will review these requests individually and respond to each of you within the next week.

Does this include my request about Sentry as well or is Sentry off limits for analytics?

Best regards,
Christopher

14

@AngelinaIgnatova You should start the four week clock after you’ve reviewed all requests and responded appropriately, and documented the new rules. People won’t make decisions until they know what’s allowed, what is not, and why.

2 Likes
15

Atlassian’s method of making it up as they go along would be fine if there wasn’t also a simultaneous migration deadline and revenue penalty date set in the very near future.

Endless source material for a stand-up comedy routine.

2 Likes
16

We’re blocked from deploying today

Error: Manifest validation failed: The value of the analytics egress is not a supported domain
Additional information: {
  "address": "events.statsigapi.net",
  "support": "To review the Analytics tool policy, go to: https://go.atlassian.com/forge-analytics-egress-support"
} (requestId: 4f957779-09fb-4e04-bdd5-5f39bb766566)

Per https://developer.atlassian.com/platform/forge/analytics-tool-policy/#analytics-criteria, Statsig shouldn’t be blocked yet.

17

@ChrisHemphill1 Please read this thread and reconsider the Connect penalty. It’s already near impossible to migrate to Forge, and things like in this thread add to the problems.

3 Likes
18

We are very concerned about the immediate enforcement of the analytics egress allowlist. Our current setup relies on two key services that would be blocked under the new rules in such a short timeframe:

  • Azure endpoints → used for Monthly Active Users (MAU) tracking and product usage analytics. This data is critical for:

    • Internal KPI reporting and portfolio governance.

    • Marketplace-level adoption and usage tracking.

    • Guiding product development decisions based on customer behavior.

  • Sentry → used for error tracking. This allows us to:

    • Identify runtime issues quickly in production with the necessary context and alerting capabilities. The console can’t handle this, especially as we pay for the logs!

    • Proactively fix problems before they impact more users.

If both are blocked without a viable alternative, we will immediately lose:

  • The ability to measure MAU and feature adoption.

  • Critical observability into app errors and reliability.

  • The foundation for reporting is required internally and expected by stakeholders.

We fully understand Atlassian’s privacy objectives, but the short timeline and lack of replacement tooling put Marketplace vendors at risk.

:backhand_index_pointing_right: Could Atlassian clarify:

  • Whether Azure Insights can be considered in scope as “product analytics” rather than observability?

  • What alternative vendors are expected to use for reliable MAU and error tracking, given that Atlassian Developer Console does not cover these needs?

  • Can a transition period be introduced to give vendors a long time (> 3 months) to reimplement analytics and observability pipelines before enforcement?

Without this, we face serious blind spots in adoption, error monitoring, and reporting that directly impact our ability to manage and grow our apps responsibly.

4 Likes
19

@AngelinaIgnatova it’s been 5 days since Kha posted and we can’t release our app. This is a security risk for customers which I don’t believe that Atlassian intended to create.

20

Thank you for your feedback on the Analytics Tools Policy.

We want to provide more details on why we implemented this policy. The analytics category under egress permissions allows app owners meeting the Runs on Atlassian criteria to maintain their badge while understanding user behaviour, gaining data-driven insights, improving user experience, and driving business value.

Since the launch, many customers have shown interest in the Runs on Atlassian badge and want to control the data sent to analytics tools, such as allowing only anonymised data streaming. After careful consideration, we concluded that we want to spend more time exploring a long term solution that would meet the needs of our mutual customers. As a result, in the short term, we will permit tools with session recording features, script aggregators, and developer observability tools. As an app developer you should understand the Shared responsibility model and keep customer data secure. In the mid-term, we will explore various long-term solutions. We commit to provide at least 4 weeks notice before making any changes to the domains currently included in the allowlist. To meet customer needs, we will update the analytics tools disclosure on the installation screen and the Privacy and Security tab on the Marketplace listing to ensure full transparency regarding the risks associated with sending data to certain analytics tools.

Once again, thank you for your feedback. We will continue to reach out for your input as we narrow down the long-term solution.