Is there a way to prevent application insights from attaching to a process and writing a startup message

SimonY-1215 95 Reputation points
2026-04-05T20:20:29.42+00:00

On Azure App Service, I have a long-running WebJob that creates another process (in .NET using new Process ).

Because application insights is enable on the App Service environment, it attaches to the new process and writes the following to stdout:

AppInsightsAgent: ETW could not be loaded 
AppInsightsAgent ETWLogger Application Insights was started succesfully. 
Application Insights was started succesfully. [ 
  '2.10.8', 
  '4c3e268b-51db-4634-b0cd-64aac8a9eee8', 
  '*********', 
  '1.3.7', 
  'bb8b4a86-c64b-40dc-90ac-0fb8e8c6e4fa', 
  '3000' 
]
  1. Prevent application insights from attaching to this single process (but still have it operational for the rest of the App Service), or
  2. Silence application insights so that it doesn't write this (or any other message) to the stdout for the process.

For context, the stdout from the new process is being consumed elsewhere and this injection from application insights is breaking the workflow.

Azure App Service
Azure App Service

Azure App Service is a service used to create and deploy scalable, mission-critical web apps.

Answer accepted by question author
Shree Hima Bindu Maganti 7,590 Reputation points Microsoft External Staff Moderator
2026-04-13T19:34:56.4166667+00:00

HI @SimonY-1215
Yes, this behavior is expected when Azure App Service codeless Application Insights monitoring is enabled, because the App Service runtime can automatically attach the Application Insights agent to supported child processes started by your WebJob. In your case, since the spawned process is Node.js, the supported way to prevent the startup banner and ETW messages from being written to stdout is to disable only the Node.js auto-instrumentation agent by adding the App Service application setting XDT_MicrosoftApplicationInsights_NodeJS = 0 under Azure Portal > App Service > Configuration > Application settings, then save and restart the app. This setting stops Application Insights from attaching to Node.js child processes while keeping monitoring enabled for your main .NET WebJob and the rest of the App Service environment. Azure’s codeless monitoring documentation confirms that runtime monitoring uses stack-specific agents and App Service settings to control instrumentation behavior.

At this time, Azure App Service does not provide a documented setting to exclude only one specific child process instance or to suppress only the startup log messages while still allowing the same Node.js agent to attach. So for scenarios where stdout is part of your workflow, disabling the Node.js agent for child processes using the above setting is the recommended and cleanest solution
https://learn.microsoft.com/en-us/azure/app-service/monitor-app-service?tabs=aspnetcore
https://learn.microsoft.com/en-us/azure/azure-monitor/app/application-insights-faq
Let me know if you have any further assistance needed.

Was this answer helpful?

1 person found this answer helpful.
0 comments
Answer accepted by question author
Praneeth Maddali 12,670 Reputation points Microsoft External Staff Moderator
2026-04-06T09:05:08.44+00:00

HI @SimonY-1215

Thanks for reaching out and providing such clear details (including the stdout output and the fact that you're spawning a Node.js process from your .NET WebJob). I completely understand how the extra Application Insights startup messages are breaking your workflow—super frustrating when you're consuming that stdout elsewhere.

The good news is this is a very common scenario with Azure App Service's codeless instrumentation, and there's a clean, supported way to fix it without touching your .NET monitoring at all.

Recommended fix: Simply disable the Node.js agent (while leaving the .NET agent fully active) by adding one application setting at the App Service level:

  • Name: XDT_MicrosoftApplicationInsights_NodeJS
  • Value: 0

You can add this in the Azure Portal under Your App Service > Settings > Configuration >Application settings, then save (the app will restart). That's it—no code changes needed.

This prevents the Node.js auto-instrumentation from attaching to your child process, so those ETW and "Application Insights was started successfully" messages will stop appearing in stdout. Your .NET WebJob and the rest of the App Service will continue to be monitored normally.

Reference:

https://learn.microsoft.com/en-us/azure/app-service/monitor-app-service?tabs=aspnetcore#using-application-settings-to-control-agent-behavior

Once you've applied the setting, give your WebJob a quick test run and let me know how it goes. If the messages persist or if you're running on Linux instead of Windows, just share a bit more detail and I'll dig in further.

If the answer is helpful,  Please do click "Accept the answer” and Yes, this can be beneficial to other community members.

If you have any other questions, let me know in the "comments" and I would be happy to help you

Was this answer helpful?

1 person found this answer helpful.
0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-04-05T20:20:38.5533333+00:00

    Application Insights autoinstrumentation on Azure App Service is controlled at the app level, not per child process. The available guidance in the context only covers:

    • Removing or avoiding the SDK when using autoinstrumentation.
    • Fixing cases where autoinstrumentation fails because of conflicting SDKs, unsupported .NET versions, or overridden hosting startup assemblies.
    • General troubleshooting and performance issues.

    There is no documented mechanism in the provided material to:

    1. Exclude a single spawned process from being instrumented while keeping autoinstrumentation enabled for the rest of the App Service, or
    2. Suppress or redirect the startup messages that the Application Insights agent writes to stdout for that specific process.

    The context does not describe any per-process opt-out flags, environment variables, or configuration switches for the agent’s console output.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.