External Logging


I want to ship Forge App error logs to an external service (elastic?).
Thus to identify production errors proactively and not to rely on user reports (logs).

I plan to use an encrypted environment variable to store the external service credentials and allow the external service as backend in the manifest to use fetch and transmit these errors.

  • Does anyone have a similar setup or any other solutions?
  • Any security/privacy concerns with this plan?



Hi @mstrelex,

  • We don’t have any best practices but it might be worthwhile looking into Sentry to get insights in your errors
  • We have recently shipped production logs which might be useful to you!
  • You cannot store or save any PII information but other data should be ok :slight_smile:
  • We also have other features that we are adding to the Developer Console which might be very useful for your use-case, so stay tuned!

Hope this helps and happy coding!


Thanks @Aryan

  1. There are many alternatives to Sentry, such as Loggly. But the question is more technical. I found this @atlassian/sentry-transport-forge - npm, and it seems like it uses the same techniques that I planned to - an environment variable for the DSN and fetch to transmit the data.
  2. To use these, I will have to ask either for actual logs archive or enable continuous log access. It’s not the same as accessing records from all users.
  3. Got it, thanks.
  4. Are you referring to App monitoring and Function errors: errors from a failed function ? Would you mind sharing more information on that?



I’ve watched you talking about these extended metrics in the Webinar.

Could you please share your opinion on whether it’s worth investing any efforts in shipping logs with errors elsewhere, or instead, it would make sense to keep waiting for this platform capability?


Hi, @mstrelex, thanks for reaching out!
Technically speaking you can use external service to access the app logs following this approach, however to allow this call to work, you must disclose these external domains by adding them as new entries in the permissions.external.fetch.backend section of the manifest.yml file of your app. Customers installing the app will need to consent to the data egress and this can be an adoption blocker for some customers as data egress is outside of their risk appetite. Based on recent feedback, we are seeing that data egress is becoming more and more important for our mutual customers, this is why we made the decision to put the control of the log access in the hands of the customer.

With the first release of Forge app monitoring you will be able to see the count of errors along with the types of errors. Initially we will categorise the errors in the following categories: Out of memory , Timeout and Unhandled exception . We will be open for feedback on this categorisation to see if there is an opportunity to improve it. As advised during the webinar, with the initial release (currently scheduled for next month), developers will have a view of the overall health of the app, drilling down to individual installations is planned for the subsequent release which will be coming later the same quarter.

BTW, I am curious to hear if you encountered any roadblocks when asking customers to enable log sharing?

1 Like

Thanks for your prompt reply @AngelinaIgnatova

I can’t yet answer your question, as the App is not yet released.
I do not anticipate significant roadblocks, but I was hoping for a larger representative sample rather than a bunch of those who were explicitly requested to enable logs sharing.

Coming from the mobile world, having App installed on thousands of devices, I looked for something like https://instabug.com/ to monitor production issues.

It sounds like the first release of the monitoring features is close to what I need. If I may ask, will this be available only in the developer console, or will there be a way to query this data and configure alerts?

1 Like

@mstrelex, we most certainly see interest from the developer community to be able to import metrics into their own observability tools and this was also raised in the Q&A after the recent Forge roadmap webinar. We will be looking into this in the mid term, but not before we ship the core set of Forge metrics first. As for alerting, this is something we will be looking at as soon as next coming quarter. Hope this helps!