ITRS named a Visionary in the 2025 Gartner® Magic Quadrant™ for Digital Experience Monitoring.

What’s new

See the latest features and product updates in Uptrends
View the API changelog and reported issues in the Incident log.

Submit a feature request

UPDATE

MAR 2025

#New scripting methods are now available in Multi-step API (MSA) monitors

The following scripting methods can now be used in the Pre-request and Post-response scripting tabs of Multi-step API (MSA) monitors:

  • ut.crypto.cert.parseCrl(bytes) — parses a certificate revocation list and returns its metadata.
  • ut.crypto.md5(value) — generates an MD5 hash of the specified value.
  • ut.crypto.sha1(value) — generates an SHA-1 hash of the specified value.
  • ut.crypto.sha256(value) — generates an SHA-256 hash of the specified value.
  • ut.crypto.sha512(value) — generates an SHA-512 hash of the specified value.
  • ut.response.bytes — returns a byte array containing the response body. Responses are limited to 100 MB.

Note that ut.response.bytes is only available in the Post-response tab of your MSA monitor. The scripting methods for generating MD5 and SHA hashes enable you to store and send values securely, ensuring data protection through hashing.

UPDATE

FEB 2025

#Introducing the Monitor permissions overview

The Summary of monitor permissions overview is now available in the User Management hub. This overview lists all your monitors and their individual operators and operator group permissions:

From the User Management hub, clicking the number of available production monitors card opens the monitor permissions overview page. Note that this feature is available to Administrators with Enterprise-level accounts.

Summary of monitor permissions

UPDATE

FEB 2025

#Introducing the API user overview

The API user overview is now available in the User Management hub. This overview lists all your operators' API information in addition to the existing individual operator’s API information in the API management tab:

From the User Management hub, clicking the View all API users button opens the new overview page, where you can view and sort the following information easily:

  • Operator — the full name of the operator using the API
  • Username — an alphanumeric string representing the API username
  • Type — the API type or where the API was used (Generic - most common API type, Mobile App, Transaction Recorder, Grafana)
  • Created — the period when the API was created
  • Last Used — the period when the API was last used (minutes, days, or Never used)
  • Description — a text that describes or explains what the API is used for
  • Delete — a button that lets you delete a specific API user
API user overview

UPDATE

FEB 2025

#Introducing new alerting variables

The following alerting variables are now available for use:

  • @alert.numberOfConsecutiveErrors — contains the total number of consecutive errors (confirmed errors) of the alert. This returns 2 when the API response is {"numberOfConsecutiveErrors": "2"}.
  • @alert.checkpointName — contains the checkpoint’s name or location where the alert was last checked. This returns Ghent, Belgium when the API response is {"checkpointName": "Ghent, Belgium"}.
  • @‌alert.responseHeaders — contains the response headers of the alert in key-value pairs. For example, this returns {"Content-Type": "text/html"} from the API response header, similar to how the values are returned for @alert.responseBody.

Note that the value of the @‌alert.responseHeaders can be empty if the Private location data protection is enabled on a private checkpoint location performing the alert check. For more information, see Alerting system variables.

UPDATE

FEB 2025

#Additional conditions for Check URLs loaded by the page

The Check URLs loaded by the page is an error condition that checks if specific page elements are loaded on your website. These page elements are the URLs displayed in your Waterfall chart, including images, files, and other website resources.

This error condition now allows you to set extra criteria for checking each page element’s metrics. By clicking the new +Add additional condition button, you can now specify the page element’s response size in bytes (B), total time in milliseconds (ms), and status code:

If you want to get errors when your image loads longer than 2 seconds or if a file results in a status code higher than 400, you can add specific criteria for each.

The Check URLs loaded by the page error condition are available for Browser or Full-Page checks and Transaction monitors. Note that for transaction monitors, you need to select the Waterfall option in a step to set the additional conditions.

Additional conditions for Check URLs loaded by the page
By using the Uptrends website, you consent to the use of cookies in accordance with our Cookie Policy.