Application Insights JavaScript SDK: browser telemetry with a CDN caveat

A browser library, not a Node.js one

The first thing the README settles is where the SDK is meant to run. This SDK is intended for browser environments and is not suitable for other environments, like Node.js applications, and for instrumenting a Node.js app the recommended SDK is the ApplicationInsights-node.js repository.

That is an unusually explicit boundary for a telemetry library, and it matters because the temptation to load the same bundle on the server is strong. The browser build carries page view tracking, script error collection and DOM interaction instrumentation, none of which has a server side equivalent, and a bundle that assumes a document and a window will misbehave under Node.js.

The second thing the README settles is the language level. ES3 support has been removed from the latest version, with a separate page documenting ES3 and IE8 support, so the current 3.x line assumes a modern browser, and the release table puts the floor at ES5, which it equates with IE9 and later.

The third is how you get telemetry out of the page. There are two ways to add Application Insights to your app: install via npm and set up an instance, or paste a script snippet at the beginning of every head tag for each page you want to monitor. The snippet route is the one that many teams start with because it needs no build step, and it is also the route the CDN notice below affects most directly.

Three release lines with three different support policies

The release table is the most useful part of the README for an adopter, because it tells you which line to be on and what each line will still receive.

The 3.x line, on the main branch, is the current supported release from April 2023. It supports dynamic configuration changes and updates after initialization, it supports all the features of v2 except with the known breaking changes from previous versions, and it does not support the previous v1.x compatible API proxy layer. It also removes support for ES3 and IE8, and the minimum supported runtime is now ES5.

The 2.x line, on the master branch, is a feature freeze from March 2023. It will only receive critical bug fixes when no workaround exists, with no new features and no back-porting from later versions. It does support adding and removing extensions and full unloading or removal of the SDK after initialization, it is the last version to support ES3, and it provides the v1.x compatible API proxy layer for upgrading from v1.x.

The 1.0.x line, on the legacy-v1 branch, is no longer actively maintained, the README says please upgrade, and its documentation has moved to a separate legacy README.

Two consequences follow. If you need to unload the SDK entirely, for example in a single page application that tears down its view, 2.x is the line that documents that capability, since the current line does not carry the v1 proxy layer and has its own set of breaking changes. And if you are on 1.x, the upgrade path is documented rather than improvised, with a separate upgrade guide and a v3 breaking changes page linked from the table.

npm install, or a snippet in every head tag

The getting started section is three steps. You create an Application Insights resource in Azure following the linked instructions, you grab the connection string from that resource, and you add Application Insights to your app.

For the npm route the install is:

        npm i --save @microsoft/applicationinsights-web

The README includes a note that typings are included with this package, so you do not need to install a separate typings package, which is one of those small differences that matters when your build has strict type checking.

The alternative is the script snippet, pasted at the beginning of every head tag for each page you want to monitor. The README links to a separate section for the snippet setup, so the two routes are documented independently, and the CDN section below applies mainly to this one.

The code itself is short. The snippet in the README looks like this:

import { ApplicationInsights } from '@microsoft/applicationinsights-web'

const appInsights = new ApplicationInsights({ config: {
  connectionString: 'YOUR_CONNECTION_STRING_GOES_HERE'
  /* ...Other Configuration Options... */
} });

The configuration object is where the connection string goes, along with the other options, and the SDK instance is created from that configuration. Because the connection string identifies the Azure resource, it is the one value that has to be correct for anything to show up in the portal, and it is also the value you change between environments, so it belongs in your deployment configuration rather than in source.

The CDN endpoint you are told to stop using

The README opens with an urgent notice, and it is the most consequential thing in the document for anyone using the snippet.

It says to avoid any global outage you must change all of your CDN usage from the az416426.vo.msecnd.net scripts path to the primary CDN endpoint at js.monitor.azure.com/scripts, and points to issue 2457 for updated details. It goes on to say that the team is investigating the options for avoiding, migrating or mitigating the situation, and that at this point it is highly likely there will be either a temporary or permanent outage of that domain, with no known way to migrate the domain to a different CDN.

That is an unusual admission to find at the top of a README, and it changes how you should read the snippet installation path. A script tag pointing at a domain that may disappear is a single point of failure for your telemetry, and a broken script tag on a page is also a broken page.

The badges in the README are themselves served from the new endpoint, with separate minified and gzip size badges pointing at the ai.3.4.5.min.js path, which is a small hint that the maintainers are already measuring the new distribution.

The practical response is straightforward. If you use the snippet, check the URL your pages reference and move it to the primary endpoint. If you bundle the SDK yourself, through npm and your own build, the CDN is not in the path at all, which is the sturdier arrangement and one of the better reasons to prefer the bundler route over pasting a tag into every head.

A rush monorepo with extensions, channels and shared code

The repository is a Rush monorepo, and the package scripts show the shape of the work. The postinstall step runs a silent rush update, the build runs a verbose rush rebuild, the test script runs a pure annotations test then a verbose rush test, and there are matching mintest, lint, perftest and purge commands, all through the same install-run-rush wrapper.

There are also tasks that are not Rush at all. The rollupes5 script builds an ES5 bundle through grunt, serve runs a local server, setVersion calls a release tool script, and there are ai-min and ai-restore commands that toggle a minimised variant of the build, with lint-fix doing an ai-restore first. A fullClean runs git clean with the ignored files flag and then reinstalls and re-runs rush update with recheck and full, which tells you how large the dependency graph is.

The directory layout matches. There is a channels directory for the telemetry channels, a common directory shared across packages, an extensions directory for the extension plugins, a shared directory, an AISKU and an AISKULight pair for the full and light user interfaces, a legacy directory for the older line, a nuget directory, an examples directory with cfgSync, dependency, shared-worker and startSpan samples, and a tools directory.

The documentation set is unusually complete for a telemetry SDK. There is an API-reference.md, a TreeShakingRecommendations.md for keeping the bundle small, a versionConflict.md, a PRIVACY file, a SUPPORT.md, a SECURITY.md, ThirdPartyNotices.txt, a CODEOWNERS file and a CONTRIBUTING.md, plus a rush.json and a tsdoc.json for the generated API docs.

Version conflicts, licensing and a busy release cadence

There is one operational rule in the README that is easy to miss and expensive to ignore. When multiple instances of Application Insights with different major version are active within a single session, errors may arise, and the README points to a separate version conflict document for the details.

That situation is easy to create by accident. A page that loads the snippet and also bundles the npm package, or a micro front end where two independently built bundles each include their own copy of the SDK, gives you two majors in one session, and the failure mode is a broken telemetry pipeline rather than a visible error.

The licence is MIT, with a LICENSE file and a separate NOTICE file at the root, and ThirdPartyNotices.txt for the dependencies. For a client side telemetry library that ships to every visitor of your site, a permissive licence is what you want.

The release history shows active maintenance. The three most recent tags are 3.4.5 on 2026-10-06, and 3.4.4 and 3.4.3 both on 2026-09-16, and the last push to the repository was on 2026-10-20, one day before the current date. The package version in the manifest matches the newest tag at 3.4.5, which is unusual for a project of this size and age and suggests the release process is automated rather than manual.

So the summary for an adopter is a well maintained browser SDK on a fast release cadence, with three historical branches still documented, a clear statement that it is not a server side library, and one CDN endpoint that the maintainers are asking users to stop using.

Editorial conclusion

Adopt the Application Insights JavaScript SDK when your web application reports telemetry into an Application Insights resource and you want the vendor's own browser library rather than a generic analytics script, and you are on the 3.x line. Do not adopt it for a Node.js service, because the README states the SDK is intended for browser environments and points to the separate ApplicationInsights-node.js repository instead, and do not stay on the 1.x line. Verify first that your pages are not loading the script from the az416426.vo.msecnd.net endpoint, since the README asks all CDN users to move to js.monitor.azure.com, check that only one major version of the SDK is active in a session because mixing versions can raise errors, and confirm the connection string you configure matches the resource you created in Azure.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/ApplicationInsights-JS on GitHub
4. README
5. Releases