Simple browser, scripted browser, and API monitors execute in the runtime environment used when the monitors were created. Your monitors won't automatically convert to newer runtimes when those runtimes release.
Monitors running on older runtimes lose out on new runtime features, so it's important that you understand which runtimes are used by your monitors.
Ping monitors are not affected by changes in runtime versions.
Use different runtimes environments
Existing monitors default to the runtime used at their time of creation. To prevent your critical monitors from breaking during future end of life processes, we recommend you convert your public monitors sooner rather than later. To convert:
Go to one.newrelic.com, click Synthetics, then select the monitor you want to upgrade.
From the Settings tab, click General.
Use the dropdown menu to switch the current runtime version.
Click Validate to check that your monitors function in the new runtime. Make any script modifications if needed.
Save.
To ensure your monitors have access to new features and perform as expected, upgrade your monitors whenever you see the Upgrade monitors button. You can also upgrade your monitors by going to one.newrelic.com> Synthetics > Upgrade monitors.
When you select Upgrade monitors, here are the options:
When editing your scripted monitors, you can click the Validate button to check if your monitors are compatible with the latest runtime. The validation process allows you to correct any errors that the latest runtime might cause with existing monitors before your monitors are upgraded.
When you select Upgrade monitors, here are the options:
Task
Description
Upgrade an incompatible monitor
If a monitor appears under Incompatible monitors:
Select the monitor in the Name column, which opens the individual monitor so you can view your scripts.
Select Validate latest and correct any errors with your monitor script.
When the monitor is validated successfully, select Upgrade.
Upgrade any validated monitors
If you have some passing monitors, upgrade them by selecting Upgrade all passing monitors to latest runtime.
Upgrade all monitors (including failing monitors)
Caution
Upgrading without validation may cause monitor outages.
If you have some failing monitors, you can skip validation and correct errors later by selecting Upgrade all monitors on account to latest runtime.
View synthetic monitoring upgrade history
To see a history of monitor version upgrades, query the NrAuditEvent.
Use environment variables in runtimes
Make your scripted monitors more contextually aware by using the $env variable properties. When the script executes, these properties represent important information about the runtime environment.
You do not need to import $env because it is readily available, similar to the $browser and $http variables. For example:
console.log('running in ' + $env.LOCATION);
$browser.get('https://example.com');
$env property
Type
Scripted browser
Scripted API test
JOB_ID
Unique ID (UUIDv4) identifying the running job
string
MONITOR_ID
Unique ID (UUIDv4) identifying the running monitor
string
ACCOUNT_ID
Unique ID (number) identifying the account that owns the monitor
number
MONITOR_TYPE
Type of monitor this job is running
string
API_VERSION
API version this monitor is using
string
LOCATION
Location where this job is running. Examples:
aws-us-east-1
123-my_location-81D (for private locations)
string
PROXY_HOST
Host of the proxy that collects HTTP traffic metrics
string
PROXY_PORT
Port of the proxy that collects HTTP traffic metrics
number
USER_DEFINED_VARIABLES (private locations)
A configurable set of variables specified by users.
Starting with the Node 16.10.0 runtime release, the API runtime will be managed separately from the browser runtime. This is the first scripted API runtime based on the got module instead of the deprecated request module. The got module is exposed in a request compatible format via the $http object. The request-like experience provided by the $http object will also be returned for any customers attempting to use request directly in the Node 16 and newer scripted API runtimes.
The API runtime is used for these monitor types:
Broken links monitor
Certificate check monitors
Scripted API monitors
Tip
If you're unsure about your monitor's runtime version, edit your monitor and check the "Runtime" drop down in the "Configure monitor" tab. You can also query the runtimeTypeVersion attribute on SyntheticCheck events where the runtimeType = 'NODE_API'.
With the Chrome 100 runtime release, the [browser runtime] (/docs/synthetics/synthetic-monitoring/using-monitors/new-runtime) is managed separately from the API runtime. This is also known as our next-generation runtime.
The browser runtime is used for these monitor types:
Scripted brower monitors
Simple browser monitors
Step monitors
Tip
If you're unsure about your monitor's runtime version, edit your monitor and check the "Runtime" drop down on the "Configure monitor" tab. You can also query the runtimeTypeVersion attribute on SyntheticCheck events where the runtimeType = 'CHROME_BROWSER'.
Chrome 100 details:
Browser: Chrome 100
Selenium WebDriver: 4.1.0 (exposed via $selenium and $webDriver with backwards compatible Selenium WebDriver 3.6 syntax exposed via $browser and $driver)
The monitor version always matches its runtime version, and determines what features the monitor can execute. The section below lists runtimes with its available features.
Tip
If you're unsure about your monitor's version, go to one.newrelic.com> Synthetics > Upgrade monitors. You won't see the Upgrade monitors option if you're already on the latest runtime version.
Here are monitor version details for all monitor types except ping:
Synthetic monitor version 0.6.x details:
Important
The synthetic monitoring runtime does not support the async/await syntax supported in Node 10.
Browser: Chrome 72
Node: 10.15.0
Selenium WebDriver: 3.6.0 (exposed via $browser and $driver)