The Transaction Check tool is based on the latest Chrome version. It supports frameworks such as React.js, Angular.js, Vue.js and so forth.

The Transaction Check monitors specific elements of a site in intervals ranging from 5 to 60 minutes, including:

• Signup forms
• Shopping carts
• User registration & login

This article will explain setup and best practices for the Uptime.com Transaction Check.

Table of Contents

• Basics
• Advanced Transaction Check Use Case
• Identify Elements
• Create Steps
• Test and Deploy a Check
• Root Cause Analysis
• Commands and Validators

Synthetic Monitoring Basics

Return

To add a new Transaction Check, click Monitoring>Checks>Add New, then select Transaction as your Check Type.

The Transaction Check script editor allows users to create steps that follow a specific set of instructions, such as visiting a site, clicking a button, or entering information into a text field. It's designed to mimic user's actions, able to click or interact with most elements of a site. Performance reporting for a transaction check includes: time to fully load the page, all images, and run initial javascript, etc. Response time is a measure of all steps.

Uptime.com supports names and IDs in the transaction editor, even without the hash (#) symbol. Look for elements identified as follows: "name=abc123" or "id=abc123". Use everything after “=” in the Transaction Check script editor. For more detailed instructions, see the Identify Elements section below.

Generally, synthetic monitoring setup looks like the following:

1. Create and name your Transaction Check
2. Identify the funnel, or sequence of actions, that the Transaction Check will follow
3. Identify the elements you want your Check to interact with
4. Create steps that follow specific actions
5. Test and deploy

Advanced Transaction Check: Check Uptime.com Homepage Test Form

Return

This Transaction Check will test the Domain Health Check form on the homepage of Uptime.com.

Recall that a successful Transaction Check follows two crucial steps:

1. Create and name your Transaction Check
2. Identify the funnel, or sequence of actions, the Transaction Check will follow

Name this check “Homepage CTA Test”, then consider what the user needs to do for this test to be considered successful. Here’s what our Transaction Check will do:

1. Go to URL https://uptime.com/
2. It will validate that element #domain-check input[name="url"] exists
3. It will fill in the field #domain-check input[name="url"] with “testdomain.com”
4. It will submit form #domain-check
5. It will validate that our URL contains: https://uptime.com/domain-health
6. It will wait for #domainHealthResultsDisplay table.listing-table to exist
7. It will validate that #domain-health-page-header h1 contains the text “testdomain.com”
8. It will wait for #domainHealthResultsDisplay div.results-table tr:nth-child(3) td to exist
9. Finally, it will wait for the element #domainHealthResultsDisplay div.results-table .listing-table to contain the text “Get DNS Records”.

This screenshot provides a visual reference of our steps:

Steps 1-4 all take place on the URL http://Uptime.com. The first step visits the URL, the next validates the form we’re testing exists, then fills in our requested data before submitting this form.

Step 5 validates that submitting the form sends us to the next URL in our funnel. Step 6 waits for the domain health results table to load (but not the results themselves, that comes in Step 8). In Step 7, our Transaction ensures the page is showing the Domain Health Check for “testdomain.com” and not some other value.

Step 8 then waits again for any javascript to complete and for the results of the health check to begin appearing on page. Finally, Step 9 ensures the results table has a row showing “Get DNS Records”.

The green “Run Test” button will start a Transaction Check that goes through each step that we have defined. It records the average page load time, and other technical details, when it performs a given check. Once complete, we can download the HTML of each URL and show details.

Details include:  URL, status code, cookies, response headers and request headers.

Assuming everything we entered checks out, we will see values that define the average load time for all URLs being tracked within this test alongside the option: View Browser Console.

The Browser Console provides a snapshot of the GET and POST requests Uptime.com used in the Transaction Check, as well as any console output logged by Javascript code. It reports status codes and technical data useful for reviewing the steps of a check for unnecessary redirects and other issues or errors.

We finalize and deploy a Transaction Check by clicking the blue Save button.

The following sections will dive into this example in greater detail, or you can refer to this article on Improving your Transaction Check.

Identify Elements

Return

If you are familiar with your browser’s Inspector functionality, feel free to skip this section.

In both Chrome and Firefox, pressing Ctrl+Shift+C/Cmd+Shift+C opens the Inspector. You can use this tool to highlight elements of a webpage and determine its name or ID.

Inspect in Chrome

Inspect in Firefox

Alternatively, you may right-click on a specific element and click Inspect or Inspect Element depending on whether you are using Chrome or Firefox/Edge.  The Inspector shows your element within the code of a website. Right click the highlighted portion of code, then click Copy Selector from the Copy submenu and paste the Selector into the Transaction Check script editor.

Uptime.com also includes functionality to select elements based on what you type. Visit a URL during the first step, then run a test. Uptime.com will be able to identify the element you’re looking for as you type it into any “Element” field after that initial test. This functionality can help with proper syntax and is sometimes useful when two Selectors are similar in nature.

Identify Elements - Advanced Usage

In addition to the above, advanced users with knowledge of CSS3 selectors may use the full range of CSS3 syntax in order to identify HTML elements in any “Element” field of your transaction. You can also review these “CSS Selectors” from W3 Schools for a reference; here are some examples to get you started:

#cart input.quantity

Find the INPUT element with “class=quantity” which is a descendant of the element that has “id=cart”.

#cart > input.quantity

Find the INPUT element with “class=quantity” which is a direct child of the element that has “id=cart”.

#cart + button.submit

Find the BUTTON element with “class=submit” immediately following the element with “id=cart”.

#cart ~ h3

Find the H3 element immediately preceding the element with “id=cart”.

ul#items > li:nth-child(3)

Find the LI element which is the 3rd direct child of the UL element with “id=items”.

div[data-type]

Find the DIV element that has a “data-type” attribute with any value.

a[href=“/homepage”]

Find the A element (anchor/hyperlink) which has a “href” attribute equal to “/homepage”.

div[class~=“special”]

Find the DIV element whose “class” attribute value is a space-separated list of words, one of which is exactly “special”.

div[class^=“prefix”]

Find the DIV element whose “class” attribute value begins with “prefix”.

div[class$=“suffix”]

Find the DIV element whose “class” attribute value ends with “suffix”.

div[class*=“substring”]

Find the DIV element whose “class” attribute value contains at least one occurrence of “substring”.

Create Steps for Synthetic Monitoring

Return

Click Add a New Step in the Transaction Check script editor.

Steps are broken down into two categories: Commands and Validations. Commands (color-coded blue) act as tasks to complete or (more broadly) steps for a Transaction Check, Validations (color-coded green) verify elements that should be present before registering a failure.

Select either a Command or Validation, using the Run Test button to check each step as you create your check.

See the Commands and Validators section below for a breakdown of each potential step.

Delete, Edit, or Add Steps

If you need to add a new step that should precede a prior step already created, simply drag the new step to its proper place in the Transaction Check steps. To delete a step, click the small X to the right of the step. You may also click each step to edit its parameters.

Testing and Deploying Your Check

Return

Use Run Test to run a single Transaction Check based on your steps to catch errors in your setup before deployment. When your entire test completes successfully, your synthetic monitoring is ready to deploy.

Failed Checks

When a probe server detects downtime or fails to register as UP, the Transaction Check you've configured will attempt a retry based on the number of retry attempts you've configured for this check. Please note: The retry intervals for Transaction checks are two minutes, as opposed to one minute for other checks.  

Uptime.com offers multiple methods of gaining insight into a failed test. The first is a Camera icon that links to a downloadable screenshot of what the Uptime.com tool encountered. The Check also displays a warning icon, and accompanying message, with technical details about the failure.

Additionally, you may view page source after navigation (before and after javascript has executed) with downloadable files that you can review for accuracy. Use the "Info circle" icon to review technical details of each requested URL such as headers and cookies. The "File" icon on the left downloads the HTML code before rendering, and the middle "Code" icon downloads the HTML DOM after rendering & javascript.

Typically, the best way to correct an error in testing is to inspect each step carefully and be sure you’re using the proper URL, text, element ID, name or CSS selector. Also review syntax.

Root Cause Analysis

Return

If the Check registers a failure once it is deployed, the Root Cause Analysis tool (available via Reports>Alerts) can provide further insights. Root Cause Analysis includes a screenshot of what Uptime.com encountered, along with technical data about the servers reporting failure, and which step triggered the alert.

This screenshot shows how to access this tool:

And here is a sample Root Cause Analysis. Note the screenshot, and technical data involving Step 4 (See Use Case):

Commands and Validators

Return

A mix of Commands and Validators make for a useful Transaction Check. It’s important to understand how each functions when you’re considering potential Transaction Checks.

Commands

Authentication & Settings

Sets HTTP basic auth and other settings. You will need a username and password, We highly recommend that you create unprivileged test credentials for any checks that utilize HTTP basic auth.

Uptime.com includes password masking for passwords used in synthetic monitoring. Ordinarily, Uptime.com identifies a password field and automatically obscures the text.

In some cases, Uptime.com is not able to detect the field is a password field and will not mask its entries. In these cases, you can use the following example as a guide to create a password element Uptime.com will detect:

Non-detected password element:

div.foo > input[name=testpassword]

Adjust to:

body:not([data-pw]) div.foo > input[name=testpassword]

Go To URL

Navigates the browser to the URL that you specify. Note that the target page must load within 30 seconds otherwise the transaction will fail with a page load timeout.

Click Element

Clicks on the specified HTML element. Use the id, name or CSS selector of the element you wish to interact with.

Check Checkbox/Radio Button

Checks a specified checkbox or radio button. Use the id, name or CSS selector of the element you wish to interact with.

Uncheck Checkbox/Radio Button

Unchecks a specified checkbox or radio button. Use the id, name or CSS selector of the element you wish to interact with.

Wait for Element To Exist

Waits until the specified HTML element exists on the page. Use the id, name or CSS selector of the element you are waiting for. Please note that the element must appear within 25 seconds otherwise the transaction will fail with a wait timeout. Typically used to wait for the page to finish rendering, or for the javascript to finish running.

Wait for Element To Contain

Waits until the specified HTML element contains the given text. Use the id, name or CSS selector to specify the element, then define the text it should contain. Please note that the element must appear within 25 seconds otherwise the transaction will fail with a wait timeout.

Wait for 1 Second

Pauses for 1 second and then continue the next step. Use this as a last resort if you need the browser to wait for some javascript to run. Usually using one of the “Wait for Element” steps is much more reliable.

Validations

HTTP Status Code Should Be

Checks that the HTTP status code matches the specified status (eg. 200 or 404). You must enter a numeric HTTP status code.

URL Should Not Contain

Checks that the browser’s URL does not contain the given text.

Title Should Contain

Checks that the page title attribute contains the given text.

Title Should Not Contain

Checks that the page title attribute does not contain the given text.

Element Should Exist

Checks that the specified HTML element exists on the page. Use the id, name or CSS selector of the element that should exist.

Element Should Contain

Checks that the specified HTML element contains the given text. Use the id, name or CSS selector of the element, then define that text that it should contain.

Element Should Not Contain

Checks that the specified HTML element does not contain the given text. Use the id, name or CSS selector of the element, then define the text it should not contain.

Checkbox/Radio Button Should Be Checked

Verify that the specified checkbox/radio button is checked. Use the id, name or CSS selector of the element you wish to interact with.

Checkbox/Radio Button Should Not Be Checked

Verify that the specified checkbox/radio button is not checked. Use the id, name or CSS selector of the element you wish to interact with.