An uptime test lets you make a request to a specified URL or port address and monitor its response time and response code. Uptime tests record three metrics from each run: response time, DNS time, and time to first byte. For an example, see Monitor the performance of a user-facing application.

Learn more about uptime tests.

Create an HTTP test

1. Select Digital Experience > Synthetic tests.

2. On Synthetic tests, select Create new test > HTTP test. The test creation view opens.

3. On the test creation view configure each test section:

   • Details section:

     • In Name, enter a name for your test. You will use this name to identify data from the test in your alerts and reports.

     • In Custom properties, add custom properties.

   • Request section:

     • In Request type field, select the Method, enter the full URL of the page you want to test, including http or https, and enter the Port.

     • To validate your test configuration, select Try now. Results from Try now runs aren’t stored. See Validate your test configuration.

     • In Request headers, add the custom headers to send with each request.

     • Set up auto retries in case the test initially fails.

   • Security section:

     • Set up authentication.

     • Set up TLS/SSL validation.

     • In Validations, set up assertions.

   • In Test configuration set up User agent, Locations, Frequency, and Round-robin scheduling.

   • In Detectors set up detectors.

4. Select Create.

   This redirects you to the Test History page for your new test. If you just created the test, allow at least 1 test frequency interval for your test to begin collecting synthetic data.

Create a port test

1. Select Digital Experience > Synthetic tests.

2. On Synthetic tests, select Create new test > Port test. The test creation view opens.

3. On the test creation view configure each test section:

   • In the Name field, enter a name for your test. You will use this name to identify data from the test in your alerts and reports.

   • In the Address field, use the drop-down list to indicate whether the port you are monitoring follows TCP or UDP protocol, and enter the host and port addresses.

   • In Details set up User agent, Locations, Frequency, and Round-robin scheduling.

4. Select Create.

   This redirects you to the Test History page for your new test. If you just created the test, allow at least 1 test frequency interval for your test to begin collecting synthetic data.

Add advanced settings

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.

Authentication [browser]

Add credentials to authenticate with sites that require additional security protocols, for example from within a corporate network. To use authentication, a username and password need to be provided. The username can be entered as plain text or be defined by a global variable, but the password must be defined using a global variable. It is recommended to use a concealed global variable for your password to create an additional layer of security for your credentials. For details, see What happens when you conceal a global variable.

When executing the browser test, the Chrome browser is configured with the credentials defined in the test configuration. Authentication is not integrated at the OS level, and no authentication processing happens in the runner itself. Credentials are passed directly to Chrome for handling.

At this time, Chrome supports the following authentication protocols:

• Basic Authentication

• NTLM

• Kerberos (with limitations)

• Digest

Chrome supports Kerberos authentication only when it can infer the correct Kerberos service principal name (SPN) based on standard conventions. This support doesn't include Kerberos Credentials Delegation (Forwardable Tickets).

Auto-retry

Run a test again automatically if it fails without any user intervention. It's a best practice to turn on auto-retry to reduce unnecessary failures from temporary interruptions like a network issue, timeouts, or other issues. Auto-retry runs do not impact subscription usage, only the completed run result counts towards your subscription usage. Auto-retry requires at least runner version 0.9.29.

Chrome flags [browser]

Google Chrome flags are a helpful tool for troubleshooting. Activate browser features that are not available by default to test custom browser configurations and specialized use cases, like a proxy server.

For more, see What are Chrome flags? in the Google Chrome Developer guide.

Note: Global variables are incompatible with Chrome flags.

These are the flags available:

Chrome flag	Description
--disable-http2	Requests are made using using http/1.1 instead of http/2.0. This HTTP version is viewable in the HAR file.
--disable-quic	Deactivates QUIC, which also deactivates HTTP3.
--disable-web-security	Deactivate enforcement of same origin policy.
--unsafely-treat-insecure-origin-as-secure=http://a.test,http://b.test	Treat given insecure origin as secure. Multiple origins can be supplied in a comma-separated list.
--proxy-bypass-list="*.google.com;*foo.com;127.0.0.1:8080"	Proxy bypass list for any specified proxy for the given semi-colon-separated list of hosts. This flag must be used with --proxy-server.
--proxy-server="foopy:8080"	Uses a specified proxy server to override default settings.
--no-proxy-server	Don’t use a proxy server, always make direct connections. This flag can be used to override any other proxy server flags that you may have set up in a private location.

Collect interactive metrics [browser]

Interactive metrics are collected by default for each page in the test flow, but this can result in longer run durations depending on how long it takes for the page to become fully interactive. You can turn off interactive metrics in advanced settings to speed up run durations and see results faster. If you turn off interactive metrics then the following metrics might be missing from your test:

• First CPU idle: Time until the page is minimally interactive and responds to user input.

• Time to interactive: This measures the time until the page responds to user input quickly. It is used to identify when the page is actually usable, not just when the page load looks complete.

• Lighthouse score: A weighted aggregation of several browser test metric values calculated using v10 of the Lighthouse desktop scoring algorithm. See https://developer.chrome.com/docs/lighthouse/performance/performance-scoring#lighthouse_10 in the Google developer documentation to learn more about Lighthouse scoring.

Cookies [browser]

Set cookies in the browser before the test starts. For example, your site may respond to a cookie to circumvent a pop-up modal from randomly appearing and interfering with your test flow.

To set a cookie, a key and value must be provided. A domain and path may optionally be provided to only apply the cookie to requests to the given domain and/or path. By default, the cookie will apply to the to the domain of the starting URL of the check and all paths on that domain. Splunk Synthetics Monitoring uses the public suffix list to determine the domain.

Custom headers [browser]

Specify custom headers to send with each request. For example, you can add a header in your request to filter out data from back-end analytics. To add a custom header, a name and value are required. You may optionally provide a domain to scope the header to. If a domain is specified, only requests sent to that domain will include the header. Otherwise the header will be included in requests to all domains.

You can also use headers to change the user agent. The default user agent is the given one for the selected device, which updates whenever the Chrome version changes for synthetic runners. To customize the user agent header for all domains, turn off the "Use device default" toggle next to the user agent field and then enter the new value. To change the user agent for specific domains, add a custom header and provide the domain you wish to apply that user agent to. If a domain is not specified, the top-level user agent setting takes precedence.

Custom headers can be used to set cookies, but we recommend using the Cookies settings instead outlined in the section below.

Custom properties [browser]

Add custom properties in the test creation page in advanced settings. Use key-value pairs to create custom properties to filter and group dashboards, charts, and create alerts. A list of suggested custom properties is available for each test based on the tags associated with your test. For example: env:test, role:developer, product:rum. When you have multiple key-value pairs the logic is AND among the results. So in this case, the results show all tests for the RUM product with a developer role in the environment test.

Custom properties are single valued and don't support multiple values, like region:eu, us. For each test, you can only use one and unique key. For example, you can have env1:test and env:test in the same test, but you can't have env:test, and env:prod.

Key requirements:

• Keys must start with an uppercase or lowercase letter. Keys can't start with special characters or numbers.

• The remainder of the key can contain letters, numbers, underscores and hyphens.

• Keys can't be named test_id or test.

• Key size can't exceed 128 characters.

Detectors

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. See Detectors and alerts to learn more.

Device type

In the Device Type field, use the list to select the device from which you want to conduct the test.

Excluded files [browser]

You can configure your browser test to ignore specific file types or patterns so that it skips all HTTP requests that match those file types or patterns.

Exclusion rules are useful to:

• Prevent false alerts from test analytics.

• Test the performance of a page with or without specific resources loading.

• Prevent specific third-party services from loading, such as random pop-ups from third-party services.

• Ignore files that are known to cause performance problems.

To create an exclusion rule:

1. On the browser test's configuration page, select the Advanced toggle.

2. Scroll down to the Custom content section.

3. Select Add excluded file.

4. Select a value in File type:

   • To exclude all files of a common predefined type, select that type.

   • To exclude all file types except those that match the value you specify, select All Except and specify a value or regular expression.

   • To use regular expressions, select Custom and specify a value or regular expression.

     For example:

     • To exclude a specific domain, including all of its subdomains, enter domainname\.com

     • To exclude only the subdomains of a specific domain, but not the domain itself, enter .+\.domainname\.com

     • To exclude a JavaScript app, enter domainname\.com/appname\.js

     • To exclude entire directories, enter domainname\.com/directoryname\/.+

Note: All Except inclusions take precedence over other exclusions. The order in which you specify exclusions doesn't matter except when you're using a combination of All Except and Custom.

Frequency

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

Host overrides [browser]

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 from a specific CDN edge node.

You can also indicate whether to retain the original HOST header by activating Keep host headers. If activated, the original request's headers remain intact (recommended). If deactivated, a change in the HOST header to the new host might occur, potentially leading to an internal direct (307). Keep host headers is activated by default.

Note: Host overrides apply only to the exact hostname you specify. They don't automatically apply to subdomains. In other words, host overrides don't support wildcards. If you need to override any subdomains, you must create a separate host override for each subdomain's fully qualified domain name (FQDN). For example, if you create a host override for domainA.com to domainB.com, requests to domainA.com are redirected to domainB.com, but requests to mail.domainA.com are not automatically redirected to mail.domainB.com. You must explicitly create a separate host override for mail.domainA.com.

HTTP method

Select an HTTP method and add a payload.

Locations

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

Round robin

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

SSL/TLS validation [browser]

When activated, this feature is used to enforce the validation of expired, invalid hostname, or untrusted issuer on TLS/SSL certificates. Splunk Synthetics supports a minimum TLS version of 1.2 (TLSv1_2).

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

View your 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 test results

See Interpret uptime test results.