What problem are you trying to solve?

Focus on the what and why of the need you have, not the how you'd like it solved.

We are a production user relying on Atlas Stream Processor, and we frequently encounter sudden Stream Processor Memory Errors due to the limitation of the internalQueryJavaScriptHeapSizeLimitMB parameter. Since we lack visibility into the internal JavaScript heap usage, we are forced into a reactive operational model. We must wait for an error to occur, resulting in significant, unplanned downtime and requiring us to open urgent support cases for a manual parameter increase. This current process is costly and destabilizes our production environment.

What would you like to see happen?

Describe the desired outcome or enhancement.

We require the exposure of internal JavaScript Heap Usage metrics from the Atlas Stream Processor. Specifically, we would like to see exportable metrics that show the Current JavaScript Heap Usage (in MB) and the Maximum Configured Heap Limit (internalQueryJavaScriptHeapSizeLimitMB). Ideally, these metrics should be accessible through Atlas Monitoring or an external monitoring integration (like Datadog).

Why is this important to you or your team?

Explain how the request adds value or solves a business need.

This feature is critical for enabling proactive operational management. Direct visibility into heap usage is essential for setting up predictive alerts. This would allow our team to detect when heap usage exceeds a critical safety threshold (e.g., 80% of the limit) and request a parameter increase before a production error or crash occurs. Ultimately, this will drastically reduce unplanned downtime, prevent the repeated opening of reactive support tickets, and ensure the stability and scalability of our real-time processing pipeline.

What steps, if any, are you taking today to manage this problem?

Today, we are forced to manage this problem reactively. We must then open a support ticket to request an increase to the internalQueryJavaScriptHeapSizeLimitMB parameter after the error has already impacted our production workflow.