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
- Advanced Transaction Check Use Case
- Identify Elements
- Create Steps
- Test and Deploy a Check
- Root Cause Analysis
- Commands and Validators
Synthetic Monitoring Basics
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.
Please note: The Uptime.com transaction check tool will follow up to 20 redirects.
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:
- Create and name your Transaction Check
- Identify the funnel, or sequence of actions, that the Transaction Check will follow
- Identify the elements you want your Check to interact with
- Create steps that follow specific actions
- Test and deploy
Advanced Transaction Check: Check Uptime.com Homepage Test Form
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:
- Create and name your Transaction Check
- 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:
- Go to URL https://uptime.com/
- It will validate that element #domain-check input[name="url"] exists
- It will fill in the field #domain-check input[name="url"] with “testdomain.com”
- It will submit form #domain-check
- It will validate that our URL contains: https://uptime.com/domain-health
- It will wait for #domainHealthResultsDisplay table.listing-table to exist
- It will validate that #domain-health-page-header h1 contains the text “testdomain.com”
- It will wait for #domainHealthResultsDisplay div.results-table tr:nth-child(3) td to exist
- 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.
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.
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.
First, we need to successfully select and identify elements so we can direct the Transaction Check with commands and validations.
Here are all possible methods of referencing elements within the Transaction Check editor:
- Value of element "id" attribute
- Value of element "name" attribute
- Element CSS selector
- Element XPath selector
If there are multiple matching elements, the first element is used.
If you are familiar with your browser’s Inspector functionality, feel free to skip this section.
Using Your Browser
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.
Alternatively, you may right-click on a specific element and click Open Inspector. The Inspector shows your element within the code of a website. Right-click the highlighted portion of code, then click Copy Selector and paste the Selector into the Transaction Check script editor.
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 Identify Element
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 identify the element you’re looking for as you type it into any “Element” field after that initial test. The tool lists button, input, select, textarea and link (a) elements first for easy reference.
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 and XPath may use the full range of CSS3/XPath syntax in order to identify HTML elements in any “Element” field of your transaction. You can run a Google search for “CSS3 Selectors” or “XPath” for a full reference; here are some examples to get you started:
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”.
Find the DIV element that has a “data-type” attribute with any value.
Find the A element (anchor/hyperlink) which has a “href” attribute equal to “/homepage”.
Find the DIV element whose “class” attribute value is a space-separated list of words, one of which is exactly “special”.
Find the DIV element whose “class” attribute value begins with “prefix”.
Find the DIV element whose “class” attribute value ends with “suffix”.
Find the DIV element whose “class” attribute value contains at least one occurrence of “substring”.
Create Steps for Synthetic Monitoring
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, and be sure to test 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
Use Run Test when you have finished creating your Transaction Check to verify all steps are working as intended. This test will catch errors in your setup before deployment. When the entire test completes successfully, your synthetic monitoring is ready to deploy.
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.
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.
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
Authentication & Settings
Sets HTTP basic auth and other settings including HTTP Headers, Browser Viewport Size, and whether to run the check as Mobile.
Basic Auth: Allows you to provide credentials for pages behind Basic HTTP Authentication. You will need a username and password. We highly recommend that you create unprivileged test credentials for any checks that utilize HTTP basic auth.
HTTP Headers: Defines HTTP Headers to be sent with a request. User-Agent is disabled. HTTP Headers must be separated by line break in the Name: value format.
Screen Size: Defines the viewport size the check will run, or the device the check emulates. The default is 1024x768.
Mobile: Adds a Mobile flag into the request User-Agent string. When this option is used, the browser also takes into account a page’s `meta viewport` tag and provides touch events support.
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. Navigation is considered finished when the load event is fired.
Clicks on the specified HTML element. Use the id, name or CSS selector of the element you wish to interact with. Users can define Left, Middle, or Right click, with options to Single, Double, or Triple click.
Performs a mouse hover over the specified element. Use this command for elements that utilize the :hover selector.
Focuses on the specified HTML Element. Use this Command for elements that utilize the :focus selector.
Fill in Element with Text
Fill in a form's text, password, hidden, select, or textarea field with the given text or value.
Check/Uncheck Checkbox/Radio Button
Checks or does not check a specified checkbox or radio button. Use the id, name or CSS selector of the element you wish to interact with.
Submit Form Element
Submit the specified form (can also be done by button click)
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.
Wait for Element To Contain Text
Waits until the specified HTML element appears and then waits for the element to contain the given text. Use the id, name or CSS selector to specify the element, then define the text it should contain. Users can tick a box to enable regex matching as needed. Please note that the element must appear within 25 seconds otherwise the transaction will fail with a wait timeout.
Wait for 1 Second
Set a variable that can be used in subsequent steps. To use this variable in other steps as either an input or validation value, enclose the variable name in dollar signs ($). For example, you can use a variable such as CLIENT_NAME in a validation step text parameter as “Welcome, $CLIENT_NAME$”. The variable value can consist of alphanumeric characters, as well as an underscore. Variable names are case insensitive. The value of the "Options" field is treated differently depending on its variable type. Below are explanations per each type:
Options: Element Name, ID, CSS Selector or XPath
The variable value is set from the contents of the element you’ve referenced.
Current Date & Time
Options: Format string, eg MMM DD, YYYY h:mma z (Please utilize this link for all format specifiers)
The variable’s value is the current date and/or time in UTC. Use the specified format as cited/linked above.
- [Number-]Number, e.g. 100 or 1705-1980 - Random integer number in a specified range, or from 0 to specified number.
- [Number:]List, e.g. 3:1,a,b,c,37 - Random string composed from Number (default 1) elements of List. The result from the example could be: 1b37.
The value of this variable is dependent on the string you’ve defined.
HTTP Status Code Should Be Status
Checks that the HTTP status code matches the specified status (eg. 200 or 404). You must enter a numeric HTTP status code.
URL Should/Should Not Contain
Checks that the browser’s URL does or does not contain the given text or regex option (if enabled). Users can tick a box to enable regex as needed. Please note: regular expressions can also contain variables.
Title Should/Should Not Contain Text
Checks that the page title attribute does or does not contain the given text or regex option (if enabled). Users can tick a box to enable regex as needed. Please note: regular expressions can also contain variables.
Element Should/Should Not Exist
Checks that the specified HTML element does or does not exist on the page. Use the id, name or CSS selector of the element that should exist.
Element Should/Should Not Contain Text
Checks that the specified HTML element does or does not contain the given text or regex option (if enabled). Use the id, name, or CSS selector of the element, then define that text that it should contain. Users can tick a box to enable regex as needed. Please note: regular expressions can also contain variables.
Checkbox/Radio Button Should/Should Not Be Checked
Verify that the specified checkbox/radio button is or is not checked. Use the id, name or CSS selector of the element you wish to interact with.