Synthetic monitoring with the Uptime.com transaction check can monitor important customer pathways in intervals ranging from 1 minute to multiple days, depending on the type of check.
If you are looking for quick tips to improve your checks, see our tips article.
See our article about commands and validations.
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.
This article will explain setup and use cases for the Uptime.com Transaction Check. For instructions on how to use the Transaction Recorder, see this article.
To skip to a specific section of the "Transaction Check Basics" video, click the links with the !
Table of Contents
- What Can Synthetic Monitoring Do?
- Synthetic Monitoring Basics
- Create Steps
- Delete, Edit, Copy Selector, or Add Steps
- Short Running Synthetic Transaction (Micro Transaction)
- Advanced Transaction Check Use Case
- Browser Console Output
- Extended Transaction Check
- Test and Deploy a Check
- Identify Elements
- FAQ
- Use Cases and Examples
What Can Synthetic Monitoring Do?
The Transaction Check is a multi-step advanced check that monitors specific elements of a site, including:
- Signup forms
- Shopping carts
- User registration & login
- Dashboard rendering
- Testing marketing pages
Synthetic Monitoring Basics
To add a new Transaction Check, click Monitoring > 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: 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.
Generally, Transaction Check setup looks like the following:
- Create and name your Transaction Check
- Create steps for the pathway, or sequence of actions, that the Transaction Check will follow
- Identify any elements you want your Check to interact with
- Add validators to ensure elements exist or navigation completed
- Test and deploy
Create Steps for Synthetic Monitoring
While editing a Transaction check, click Add Step in the Transaction Check script editor.
Steps are broken down into two categories: Commands and Validators. Commands (color-coded blue) act as tasks to complete or (more broadly) steps for a Transaction Check, Validators (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.
Delete, Edit, Copy Selector, or Add Steps
If you need to add a new step that should precede a prior step already created, use one of the following methods:
- Click “+ Add Step”, then click and drag the step by its number to its intended location
- Click the three dot menu from any step followed by Add step below as depicted:
To delete a step, select Delete Step from the three dot menu.
Click any step to edit its parameters.
To copy an element selector, click the three dot submenu and select the option as depicted:
Note: Our standard Transaction Checks include a global timeout limit of 60 seconds for all steps to complete, regardless of the number of steps. In such a case you will receive an alert with the error “global script timeout."
Short Running Synthetic Transaction (Micro Transaction)
Transaction checks also have the option to run as frequently as a 1 minute interval, (also called a Micro Transaction). When frequency is set to 1 minute, the transaction test will be limited to a max of 30 seconds timeout, and the number of allowed monitoring locations is limited to 3.
The retry interval will be reduced also to 1 minute in the case of a Micro Transaction only.
Please note: This feature is only available on the Premium account plan. You can contact support@uptime.com to set up a special configuration that allows for a higher number of locations (up to 5) on the transaction test.
When on a Free Trial & attempting to check out, a subscription to the Starter or Essential plans will not be possible as this is a Premium feature. To subscribe to a Starter or Essential plan, remove the micro transaction check or adjust the frequency to 5 minutes or above.
Advanced Transaction Check: Check Uptime.com Homepage Test Form
This Transaction Check will test the Uptime Intelligent Analyzer form on the homepage of Uptime.com.
Here’s what our Transaction Check will do:
1. Go to URL https://uptime.com/
The Uptime.com Transaction Check’s Go to URL command will follow up to 20 redirects. If you are using the Uptime.com transaction check recorder, you must use a URL that begins with HTTPS.
2. It will wait for element #domain-check input[name="url"] to exist
Validation does not wait long for elements to load. We will use a wait for step to detect an element we need to interact with, in this case a form input element.
3. It will fill in the field #domain-check input[name="url"] with “testdomain.com”
4. It will click #domain-check
5. It will validate that our URL contains: https://uptime.com/domain-health
We will use a validator here because the URL should not change, so we do not need to wait for some prior element to exist.
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”
This validator will help ensure the check is delivering our intended results, as the check screen prints the domain name that was in the user’s request.
This screenshot provides a visual reference of our steps:
Click Run Test to test and debug your work. Tip: fill in input elements, not div containers, and always use specific selectors when you go through each step.
Run Test records the page load time for each step, along with other technical details, like the waterfall and browser console output.
We can also download the HTML for each navigation step and show more details including: 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 each step within this test alongside the option: View Browser Console.
Finalize and deploy a Transaction Check by clicking the blue Save button.
Browser Console Output
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 each step including status codes, variable values, and technical data useful for reviewing a check for unnecessary redirects, script failures, and other issues or errors.
Note on Browser Console Log: Transaction checks that are run on a page which also contain a RUM collector script will not record events generated by Uptime.com checks. When running a transaction check on a page that also includes a RUM collector script, you may see the following message:
Response 406 received for https://www.rumcollector.uptime.com
Failed to load resource: the server responded with a status of 406 ()
This does not indicate an error in the transaction check; it simply means that the RUM collector script is incompatible with the transaction check.
Extended Transaction Check
For transaction checks that require longer execution times and higher level timeouts per step, the Extended Transaction Check is recommended.
The overall test time for standard transaction checks is 60 seconds, while extended transaction checks allow for a total global timeout of 15 minutes and a per-step timeout of 5 minutes.
To convert a standard transaction check to an extended transaction check, you will first need to change the timeout on the Advanced options tab to a value greater than 60 seconds.
Navigating back to the Basic options tab, you will see that EXT-TXN options are now available.
Only 1 location can be configured, which must be an EXT location or a Private Location. Additionally, there is a minimum of 30 minutes for the check interval.
Note: the Run Test tool for an extended transaction check will only work if the transaction takes less than 1 minute to complete.
This feature is available upon request by contacting Uptime.com support.
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.
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.
Data on Check Failure
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.
This screenshot is also sent with any alert the Transaction Check generates.
The Check Steps also display a red Warning icon , and the accompanying error message, with technical details about the failure.
Viewing Page Source and Request Details
Use the Info Circle icon to review the request details generated by a navigation step (such as click or Go to URL).
These details include the status code, response headers, request headers, and cookies.
You may view page source after navigation (before and after JavaScript has executed) with downloadable files that you can review for accuracy. The, Code icon on the left downloads the HTML DOM after rendering and JavaScript, while the File icon
on the right, downloads the HTML code before rendering These together will allow you to view the page as it was supplied to the probe servers at the time of failure and will allow you to view elements on the page that may be needed to adjust the checks steps.
Waterfall
The requests waterfall displays the duration of all requests, captured individually and broken down into three phases described in detail below.
-
Requesting - The total time to send a request, beginning when the browser schedules a request to be sent and ending with the last byte of the HTTP request.
-
Server Processing - The total time from request end until we receive the first byte of a response. It includes server processing time + receiving of response headers.
-
Downloading Response - The total time needed for a response to be received (downloaded) from a server (in case of cached request this time is 0).
If you notice a specific step taking excessively long, the waterfall can help provide a deeper understanding of which scripts or assets may delay the load event or prevent the step from completing.
Click the waterfall icon to see the duration of requests broken down into three phases:
For an in-depth breakdown of each request duration, hover over the time value in the “Duration” column. This will allow you to review any scripts or other elements that are performing slower than expected.
After the connection to a server is established, it is reused on subsequent requests and we see connect and SSL times as zero.
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.
Click here for more information Root Cause Analysis.
Identify Elements
Specify an element by its name or id attribute values, for example: "name=abc123" or "id=abc123". Use everything after equal sign (=) in the Transaction Check script editor, prepended with a hash/pound sign (#).
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.
First, hover over a portion of the page in the browser window, and then right-click the highlighted portion of code in the inspector window. 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.
Note: The textual content in each element can’t be longer than 1024 characters.
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 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:
#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”.
Shadow DOM Selectors
Shadow DOM allows hidden DOM trees to exist, attached to other elements within the DOM tree. The Shadow DOM element always begins with #shadow-root, and includes any elements nested beneath this selector. To select an element within the Shadow DOM of your site, you will use syntax similar to the following:
When Shadow DOM exists inside of some other element (we used ID #shadowhost1), you will structure your selector to begin with the topmost element down to the shadow-root element and then to the element you want to interact with.
The Transaction check can also select Shadow DOM when it is nested within another Shadow DOM value. Here is an example:
ID #shadowhost2 is nested within the shadow-root of shadowhost1. Within the root of shadowhost2 is the element we want: #shadowform #textinput. We can fill in text, click buttons, check boxes and more once this element is properly selected.
See the Commands and Validators article for a breakdown of each potential step type.
FAQ
What’s the total limit of script size or amount of steps?
There is no limit on the number of steps in a transaction check, though the total script size on the Uptime.com backend cannot exceed 8KB. If the script exceeds this size, you will receive the error “The Transaction/API script is too long, please reduce the number of steps or their textual content.”
What are the limits for the Extended Transaction Check?
Minutes
Minimum: 30 minutes
Maximum: 60 minutes
Hour
Minimum: 1 hour
Maximum: 60 hours
Days
Minimum: 1 day
Maximum: 60 days
Use Cases and Examples
Transaction checks support the use of the Secure Vault feature, which allows for encrypted communication of secrets such as usernames and passwords. For more information, please see our support documentation on the Secure Vault.
Want to see our checks in action? Check out our YouTube Library for more!
Comments
0 comments