Web App Monitoring

What Is Web App Monitoring?

uberAgent web app monitoring records page loads and XmlHttpRequests. For every such event, uberAgent collects the duration, the user, and the HTTP status code (plus some additional information). Web app monitoring works on every website and in all major browsers.

In the default configuration, uberAgent does not send full URLs to the backend. Instead, events are summarized per webserver (the host displayed in the browser’s address bar). Full URL monitoring can optionally be enabled for specific domains or sites of interest.

Use Cases for Web App Monitoring

By providing insights into browser and website usage, uberAgent web app monitoring enables the following use cases:

  • Measuring web page load performance
  • Calculating web app usage
  • Collecting an inventory of web apps
  • Tracking the user journey on a website

Which Data is Collected by Web App Monitoring?

The data collected as part of uberAgent web app monitoring is sent to the backend via the sourcetypes listed in the browser metrics documentation.

Additionally, some fields in the SessionDetail sourcetype (docs) are populated through web app metrics.

Requirements & Installation

Web App monitoring requires the uberAgent browser extensions to be installed in the end user’s web browser. Please see the installation instructions for details on how to install the browser extensions.

Enabling or Disabling Web App Monitoring

uberAgent web app monitoring is enabled or disabled via the BrowserPerformance* timer metrics in the configuration. In the default configuration, web app monitoring is enabled for all supported browsers.

Full URL Monitoring

What Is Full URL Monitoring?

Full URL monitoring optionally includes additional URL components in the following browser web app events or fields:

  • the sourcetype uberAgent:Application:BrowserWebRequests2 (docs)
  • the field SessionFgBrowserActiveTabHost of the sourcetype uberAgent:Session:SessionDetail (docs)

By default, full URL monitoring is disabled. The path and query components are stripped from URLs sent to the backend, i.e., uberAgent only records the scheme (e.g., https), the host (e.g., and the port (unless it’s a standard port, e.g., 443 for https).

Example of the default behavior:

  • Full URL in the browser:
  • Shortened URL in uberAgent event:

Configuring Full URL Monitoring

The default level of URL component detail can be changed by adding items in the [BrowserWebAppURL_ComponentDetail] stanza of the configuration.

Please note that URL allowlists and denylists ([BrowserWebAppURL_Filter] stanza) have precedence over [BrowserWebAppURL_ComponentDetail]. In other words, the level of detail configuration only applies to URLs that are not filtered by a deny or allow list.


Format of entries in the [BrowserWebAppURL_ComponentDetail] stanza:


Note: see the definition of URL_REGEX.

Tab URLs are matched against the regular expressions (URL_REGEX) of the items in the [BrowserWebAppURL_ComponentDetail] stanza. For matching URLs, COMPONENT_DETAIL_SPEC specifies which level of detail is recorded of the tab and request URLs.


  • Tab URLs are URLs in the browser’s address bar
  • Request URLs are URLs the browser communicates with

Optionally, the detail level of the request URL can be set independently of the detail level of the tab URL by using the second format shown above.

Multiple URL component detail specs can be specified in a single [BrowserWebAppURL_ComponentDetail] stanza. Matching is performed in the order in which items are listed. The first matching item wins.


Format of the URL component detail specification (COMPONENT_DETAIL_SPEC):

host[:path[(DEPTH)]] [:query[(PARAMS)]]


  • DEPTH: the number of path elements to include. Without DEPTH, the entire path is included.
  • PARAMS: comma-separated list of query parameters to include. Without PARAMS, all query parameters are included.

Examples: Same Level of Detail for Tab URL and Request URL

The following examples show the effect of different configurations in a scenario where the tab URL and request URL are both:


Host and Path

Capture URLs on including the path, but excluding the query:

.*\.?splunk1\.domain\.com/.*$ = host:path


Host and 2 Path Elements

Capture URLs on including the path, but only the first two elements:

.*\.?splunk1\.domain\.com/.*$ = host:path(2)


Host, Path, and Query

Capture URLs on including the path and all query parameters:

.*\.?splunk1\.domain\.com/.*$ = host:path:query


Host, 1 Path Element, and 1 Query Parameter

Capture URLs on including the first path element and the query parameter earliest:

.*\.?splunk1\.domain\.com/.*$ = host:path(1):query(earliest)


Examples: Different Level of Detail for Tab URL and Request URL

The following examples show the effect of different configurations in a scenario where:

  • Tab URL:
  • Request URL:

Tab URL: Host Only, Request URL: Host and Path

Capture only the host of the tab URL, but the host and the path of the request URL:

.*\.?splunk1\.domain\.com/.*$ = host;host:path


Tab URL:
Request URL:

Tab URL: Host and Path, Request URL: Host Only

Capture the host and the path of the tab URL, but only the host of the request URL:

.*\.?splunk1\.domain\.com/.*$ = host:path;host


Tab URL:
Request URL:

Leave a Reply

Your email address will not be published. Required fields are marked *