Docs » Use an Uptime Test to test port or HTTP uptime » Set up an Uptime test

Set up an Uptime test πŸ”—

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.

Decide whether you want to set up an HTTP Uptime test or Port Uptime test, and then follow the steps below to set up your test. To learn more about the types of Uptime tests, see Use an Uptime Test to test port or HTTP uptime.

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 is configured to accommodate traffic from Splunk Synthetic Monitoring. See Configure your site to accommodate synthetic tests for instructions.

Configure an HTTP Uptime test πŸ”—

Follow these steps to set up a HTTP Uptime test:

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

  2. In the Tests section, select Add New Test and select Uptime Test from the drop-down list. This opens the New Uptime Test page.

  3. Make sure the HTTP tab is selected.

  4. 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.

  5. In the URL field, paste the URL for the page you want to test, including http or https.

  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.

Configure a Port Uptime test πŸ”—

Follow these steps to set up a Port Uptime test:

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

  2. In the Tests section, select Add New Test and select Uptime Test from the drop-down list. This opens the New Uptime Test page.

  3. Select the Port tab.

  4. 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.

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

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 Uptime 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 Uptime test results πŸ”—

See Interpret Uptime test results for an overview of run-level Uptime test results.

Advanced settings for uptime 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.

Select an HTTP method πŸ”—

Select an HTTP method and add a payload.

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.

Activate SSL/TLS validation πŸ”—

When activated, this feature is used to enforce the validation of expired, invalid hostname, or untrusted issuer on SSL/TLS certificates. When testing pre-production environments that have self-signed or invalid certificates, it’s best to leave this feature deactivated.

Add assertions πŸ”—

You can make an assertion on two values. Add two parameters along with the comparison that you would like to perform between the two. There are three types of comparisons: string, numeric, and regular expression. For string and numeric comparisons, values are coerced to the comparison type before the comparison is made. For a regular expression comparison, the first parameter is a string and the second parameter is a regular expression. An assertion step fails if the assertion is false when the step runs.

Example πŸ”—

For an example, see Scenario: Kai monitors the performance of a user-facing application.