Docs » Use a Browser test to test a webpage » Set up a Browser test

Set up a Browser test 🔗

A Browser test lets you monitor the user experience for a single page or a multi-step user flow by running a synthetic test of the URLs you provide. Use this type of test to monitor conversion paths or any path that requires multiple steps or runs JavaScript.

For each page checked in a Browser test, Splunk Synthetic Monitoring captures an HTTP Archive (HAR) file, represented in a waterfall chart, which illustrates the performance of specific resources within the page. Browser tests also capture a set of 40+ metrics. See Waterfall chart and Browser test metrics to learn more.

Note

If the site or application you are monitoring uses allow lists or block lists for visitors or an analytics tool to measure traffic, check that it’s configured to accommodate traffic from Splunk Synthetic Monitoring. See Configure your site to accommodate synthetic tests for instructions.

Set up a Browser test 🔗

Follow these steps to set up a Browser test:

  1. From the landing page of Splunk Observability Cloud, navigate to Splunk Synthetic Monitoring.

  2. Under Tests, select Add New Test and select Browser Test from the drop-down list. The test creation view opens.

  3. In the Name field, enter a name for your test.

  4. In the Go to URL field, enter the URL for the page you want to test, including http or https.

  5. To add steps and synthetic transactions to your Browser test, select Edit steps or synthetic transactions. See Add synthetic transactions to your Browser Test to learn more.

  6. As you build your test, you can use Try now to check that the configuration of your test is valid. Run results aren’t stored. For more, see Validate your test configuration with try now.

  7. (Optional) Add a wait time before a step executes. See, Example.

  8. Save your test.

Customize your test details 🔗

Use these steps to customize your test configuration and finish creating your test:

  1. In the Locations field, enter the locations from which you want to test the URL. You can select one or multiple locations.

  2. In the Device Type field, use the list to select the device from which you’d like to conduct the test.

  3. In the Frequency field, select your desired test frequency from the list.

  4. (Optional) Use the Round Robin selector to switch between options: enabling Round Robin means your test cycles through your selected locations one at a time, while disabling Round Robin runs the test from all selected locations concurrently at your selected frequency.

  5. If you want to receive alerts from this test, select + Create detector to set up a detector on the test. Use the dialog box to customize your detector.

  6. Select Submit. This redirects you to the Test History page for your new test. If you’ve just created the test, allow at least one test frequency interval for your test to begin collecting synthetic data.

  7. (Optional) Select Edit test or the three-dot Actions menu in the row for your test to edit, pause, duplicate, or delete this test.

See also 🔗

View your Browser test 🔗

Now that you created and saved a test, check whether it’s collecting data as expected:

  1. From the Tests list, select the three-dot Actions menu and select Play arrow icon to manually trigger a live run of the test, or wait for at least one duration of the test frequency you set so that the test has time to run and collect data.

  2. Select the test you’re interested in to open the Test history view, where you can view visualizations of recent test results and metrics.

Interpret your Browser test results 🔗

See Interpret Browser Test results to learn more about Browser test results.

Edit your Browser test 🔗

To edit your Browser test, do the following:

  1. Select the row for the test you want to edit in the Tests list to open the Test history view.

  2. Select Edit test to edit your test configuration.

If you change the name of your test or the name of a synthetic transaction, it may take up to 20 minutes for the updated name to appear in your charts and detectors.

Advanced settings for Browser tests 🔗

There are many reasons why you might want to configure advanced settings for your synthetics tests. Here are a few:

  • Accessing a site with a modal that appears randomly and interrupts the flow of the test. For example, a marketing modal might prompt a user to sign up for a rewards program. To circumvent this issue you can set a cookie to stop the popup modal from appearing and interfering with your test.

  • Running a test on a site that requires users to log in to access the site.

  • Specifying the type of device on which you want to run your test by setting the User-Agent header on requests.

  • Testing out a CDN. For example, you might want to load the HTML page in the browser, but rewrite the hosts for some or all requests to a new host.

  • Filtering out requests from analytics on the back end by sending a specific header in the requests.

  • Running a test on a pre-production site that has a self-signed certificate.

Set cookies 🔗

Set cookies in the browser before the test starts. For example, to circumvent a popup modal from randomly appearing and interfering with your test, you can set cookies. Any cookies that are set will apply to the domain of the starting URL of the check. Splunk Synthetics Monitoring uses the public suffix list to determine the domain.

Set custom headers 🔗

Specify custom headers to send with each request. For example, you can add a header in your request to filter out requests from analytics on the back end by sending a specific header in the requests. You can also use custom headers to set cookies.

Authentication 🔗

Add credentials to authenticate with sites that require additional security protocols, for example from within a corporate network. By using concealed global variables in the Authentication field, you create an additional layer of security for your credentials simplify the ability to share credentials across checks. For more, see What happens when you conceal a global variable?

The Authentication field is available for Browser tests in Chrome only. Firefox tests support Basic Authentication. Splunk Synthetic Monitoring supports a suite of authentication protocols. At this time, Splunk Synthetic Monitoring supports the following in Chrome:

  • Basic Authentication

  • NTLM

  • Kerberos

  • Digest

Host overrides 🔗

Add host override rules to reroute requests from one host to another. For example, you can create a host override to test an existing production site against page resources loaded from a development site or a specific CDN edge node.

Enforce SSL/TLS validation 🔗

When activated, this feature is used to enforce the validation of expired, invalid hostname, or untrusted issuer on SSL/TLS certificates.

Note

When testing pre-production environments that have self-signed or invalid certificates, it’s best to leave SSL/TLS validation feature deactivated.

Wait times 🔗

Optimize your test coverage by adding custom wait times to capture longer page loads and improve the accuracy of run results. Applications with long load times can cause a Browser test to fail. If you know that there are certain steps in a workflow that take longer than 10 seconds, add a custom wait time to your Browser test.

  • Wait times are available with Browser tests only.

  • The maximum cumulative wait time for each test is 200 seconds.

Follow these steps to configure custom wait times for your Browser tests:

  1. In Splunk Synthetic Monitoring, select Edit on the Browser test to open the configuration panel.

  2. Select New step > Wait, from the step type drop down.

  3. Add a name and the wait time in ms.

  4. When you finish instrumenting your test, save the workflow: Return to test > Save.

The following image shows how to configure a test to go to a URL, wait for 10 seconds, then log in.

This image shows a browser test with three steps: go to url, wait 20 seconds, then log in.

Example 🔗

For an example, see Scenario: Kai monitors a multi-step workflow.