Synthetics private locations runtime transition guide

New Relic is transitioning Synthetics runtime images from Node.js 16 with Chrome 134 to Node.js 22 with Chrome 146. This update addresses CVE-2026-5281 and brings the runtimes to currently supported versions. Chrome 134 is outside of Google's supported channels, and Node.js 16 reached end-of-life in September 2023.

The new runtime images are available on Docker Hub:

• newrelic/synthetics-node-api-runtime:rc1.15
• newrelic/synthetics-node-browser-runtime:rc1.15

Image tag to runtime version reference

Each rc1.x Docker Hub tag corresponds to a specific nr.runtimeVersion value reported in SyntheticCheck events. Use this table to identify which runtime version your SJM is running. You can query the nr.runtimeVersion attribute in NRQL:

SELECT uniques(nr.runtimeVersion) FROM SyntheticCheck
WHERE locationLabel = 'YOUR_PRIVATE_LOCATION' SINCE 1 day ago

Browser runtime (synthetics-node-browser-runtime)

API runtime (synthetics-node-api-runtime)

Public vs private location differences

The migration path depends on whether your monitors run on public or private locations.

Public locations: Change the Browser version dropdown in the monitor's configuration page from Chrome 134 to Latest. No infrastructure changes needed.

Private locations: You must deploy new runtime images on your synthetics job manager (SJM) infrastructure.

What's changing

Key behavioral changes

These changes may impact your existing monitors:

• HTTP keep-alive default changed. Node.js 22 defaults http.globalAgent to keepAlive: true (it was false in Node.js 16). Scripts that create custom HTTP agents without explicitly setting keepAlive: false may experience longer execution times or timeouts, as connections remain open and prevent the process from exiting.

• Higher resource usage. Chrome 146 requires more CPU and memory than Chrome 134 for the same workload. Browser runtime containers typically use 625MB-980MB of their 3.3GB default memory limit during execution, compared to lower usage on Chrome 134.

• Increased container overhead. Scripted browser monitors have an average container overhead of 6-10 seconds. Scripted API monitors average 2-4 seconds. Monitors that were close to timeout thresholds on the old runtime may now exceed them.

Choose your migration strategy

There are two approaches for private location migration. Choose based on your risk tolerance and monitor fleet size.

Option A: In-place upgrade

Upgrade all SJMs to the new runtime images. All monitors immediately run on the new runtimes.

Best for: Small monitor fleets, non-critical environments, or when you can tolerate some monitor failures during the transition.

Steps:

1. Update the DESIRED_RUNTIMES configuration on each SJM to use the new image tags.
2. Restart or redeploy the SJM.
3. Monitor results and fix any failing scripts using the Runtime Upgrades page.

Risk: Some monitors may fail until their scripts are updated to work with Node.js 22 and Chrome 146.

Option B: Parallel private location (recommended)

Create a second private location, deploy SJMs with the new runtime images there, and run monitors on both locations simultaneously for A/B comparison.

Best for: Production environments, large monitor fleets, or when you need zero disruption to existing monitoring.

Steps:

1. Create a new private location in New Relic. Give it a descriptive name.

2. Deploy one or more SJMs pointed at the new private location with the new runtime images.

3. Set up a muting rule to suppress alert noise from the new location during testing:

   Go to Alerts > Muting rules and create a rule with the condition tags.privateLocation EQUALS <your-new-location-name>.

4. Add the new private location to your monitors. Each monitor can be assigned to multiple private locations. Jobs for each location run independently — a failure on the new location does not affect results from the old location.

5. Compare results between the two locations. Use this NRQL query:

   SELECT count(*), percentage(count(*), WHERE result = 'SUCCESS') AS 'Success %',
          average(executionDuration) AS 'Avg Exec Duration'
   FROM SyntheticCheck
   SINCE 1 day ago
   FACET locationLabel, monitorName

   Copiar

6. Fix any failing monitors on the new location using the Runtime Upgrades page or by manually editing scripts.

7. Once all monitors pass on the new location, remove the old location from your monitors and decommission the old SJM infrastructure.

Trade-off: Double infrastructure cost during the transition period. You need separate hosts or cluster resources for the second set of SJMs.

Deploy SJM with new runtime images

Update your existing SJM deployment to use the new runtime image tags. The SJM itself (newrelic/synthetics-job-manager:latest) does not change — only the runtime images it pulls.

Docker

Update the DESIRED_RUNTIMES environment variable to reference the new image tags:

$
docker run \
>
  --name sjm \
>
  --restart unless-stopped \
>
  -e PRIVATE_LOCATION_KEY=YOUR_PRIVATE_LOCATION_KEY \
>
  -e "DESIRED_RUNTIMES=[newrelic/synthetics-ping-runtime:latest,newrelic/synthetics-node-api-runtime:rc1.15,newrelic/synthetics-node-browser-runtime:rc1.15]" \
>
  -v /var/run/docker.sock:/var/run/docker.sock:rw \
>
  newrelic/synthetics-job-manager:latest

If you have an existing SJM container, stop and remove it first, then start the new one:

$
docker stop YOUR_CONTAINER_NAME
$
docker rm YOUR_CONTAINER_NAME

Podman

Ensure you have completed all Podman dependencies including the Podman API service on port 8000. Then update the DESIRED_RUNTIMES:

$
podman pod create --network slirp4netns --name sjm-pod \
>
  --add-host=podman.service:YOUR_HOST_IP
$

$
podman run -d \
>
  --name sjm \
>
  --pod sjm-pod \
>
  --restart unless-stopped \
>
  -e PRIVATE_LOCATION_KEY=YOUR_PRIVATE_LOCATION_KEY \
>
  -e "DESIRED_RUNTIMES=[newrelic/synthetics-ping-runtime:latest,newrelic/synthetics-node-api-runtime:rc1.15,newrelic/synthetics-node-browser-runtime:rc1.15]" \
>
  -e CONTAINER_ENGINE=PODMAN \
>
  -e PODMAN_API_SERVICE_PORT=8000 \
>
  -e PODMAN_POD_NAME=sjm-pod \
>
  newrelic/synthetics-job-manager:latest

$
podman pull docker.io/newrelic/synthetics-node-browser-runtime:rc1.15
$
podman pull docker.io/newrelic/synthetics-node-api-runtime:rc1.15
$
podman pull docker.io/newrelic/synthetics-ping-runtime:latest

Kubernetes

Update the Helm values for the synthetics job manager chart. If you use a values.yaml file, update the runtime image tags:

$
helm repo update
$

$
helm upgrade sjm newrelic/synthetics-job-manager \
>
  --namespace YOUR_NAMESPACE \
>
  --set synthetics.privateLocationKey=YOUR_PRIVATE_LOCATION_KEY \
>
  --set-json 'synthetics.desiredRuntimes=[{"image":"newrelic/synthetics-ping-runtime","tag":"latest"},{"image":"newrelic/synthetics-node-api-runtime","tag":"rc1.15"},{"image":"newrelic/synthetics-node-browser-runtime","tag":"rc1.15"}]'

For a new installation:

$
helm install sjm newrelic/synthetics-job-manager \
>
  --namespace synthetics --create-namespace \
>
  --set synthetics.privateLocationKey=YOUR_PRIVATE_LOCATION_KEY \
>
  --set-json 'synthetics.desiredRuntimes=[{"image":"newrelic/synthetics-ping-runtime","tag":"latest"},{"image":"newrelic/synthetics-node-api-runtime","tag":"rc1.15"},{"image":"newrelic/synthetics-node-browser-runtime","tag":"rc1.15"}]'

Identify failing monitors

After deploying the new runtime images, some monitors may begin to fail. New Relic provides tools to help you identify and fix affected monitors.

Synthetics monitors page callout

A callout banner appears at the top of the Synthetics > Monitors page:

Update runtimes that are reaching end of life (75 days left)

Click See the list of monitors to fix to go to the Runtime Upgrades page.

Runtime Upgrades page

The Runtime Upgrades page at Synthetics > Runtime Upgrades shows your monitors organized into three tabs:

• Action required — Monitors that failed on the new runtime and need script fixes. Timeout errors are listed first, followed by script errors. Within each type, enabled monitors appear before disabled or muted monitors.
• Ready to update — Monitors that passed validation and are ready to be migrated.
• Updated — Monitors that have been successfully migrated.

Each monitor shows its Name, ID, Type, Location, Status, and Issue.

New Relic automatically validates your monitors against the new runtime in the background. Monitors that fail this validation appear in the Action required tab. There are two types of validation failures:

• Timeout errors — The monitor exceeded the 4-minute validation timeout. This typically means the script runs significantly slower on the new runtime.
• Script errors — The monitor encountered a runtime error such as an assertion failure, element not found, or Chrome tab crash.

NRQL queries for monitoring the transition

Use these queries to track your migration progress:

Failure rate by monitor on the new runtime:

SELECT percentage(count(*), WHERE result = 'SUCCESS') AS 'Success %',
       count(*) AS 'Total Checks'
FROM SyntheticCheck
WHERE locationLabel = 'YOUR_NEW_LOCATION'
SINCE 1 day ago
FACET monitorName

Execution duration comparison between old and new locations:

SELECT average(executionDuration) AS 'Avg Execution Duration (ms)',
       average(duration) AS 'Avg Duration (ms)',
       average(executionDuration - duration) AS 'Avg Overhead (ms)'
FROM SyntheticCheck
SINCE 1 day ago
FACET locationLabel, monitorName

Identify monitors with increased execution times:

SELECT monitorName, average(executionDuration) AS 'Avg ExecDuration'
FROM SyntheticCheck
SINCE 1 day ago
FACET monitorName, locationLabel
ORDER BY average(executionDuration) DESC

Fix failing monitors

The Runtime Upgrades page provides two options for fixing monitors:

Fix with AI

Click the ellipsis menu (⋯) on a failing monitor and select Fix with AI. New Relic AI analyzes your script and the validation error, then proposes changes to make the script compatible with the new runtime. You'll see a diff view showing exactly what changes the AI wants to make. Review the changes and approve or decline them.

Fix manually

Click Fix manually to open a script editor pre-loaded with your monitor's current script. Make your changes, then click Continue to validation. New Relic runs the edited script against the new runtime with a 185-second validation timeout. If validation passes, the monitor moves to the Ready to update tab. If it fails, you'll see the error and can try again.

Below are common issues and their fixes.

// Option 1: Set keepAlive: false
const agent = new https.Agent({ keepAlive: false });

// Option 2: Destroy the agent after use
const agent = new https.Agent({ keepAlive: true });
// ... make requests ...
agent.destroy();

// Before (may break on Node.js 22)
const url = `http://${ipv6Address}:${port}/path`;

// After
const url = `http://[${ipv6Address}]:${port}/path`;

Move to validation queue

After fixing a monitor's script (either with AI or manually), click Move to validation queue from the ellipsis menu. New Relic will run the monitor with the new runtime and verify it passes.

Enable disabled monitors

If a failing monitor was disabled, you can re-enable it from the Runtime Upgrades page by selecting Enable monitor from the ellipsis menu. This allows the monitor to be tested on the new runtime.

Kick off the update

Once monitors in the Ready to update tab have been validated, you can kick off the runtime update to complete the migration for those monitors.

Troubleshooting

Common issues

Useful NRQL queries

Check for monitors with increased failure rates:

SELECT percentage(count(*), WHERE result = 'FAILED') AS 'Failure %'
FROM SyntheticCheck
SINCE 1 day ago
FACET monitorName
WHERE percentage(count(*), WHERE result = 'FAILED') > 0

Compare execution duration before and after migration:

SELECT average(executionDuration) AS 'Avg ExecDuration',
       max(executionDuration) AS 'Max ExecDuration',
       average(executionDuration - duration) AS 'Avg Overhead'
FROM SyntheticCheck
SINCE 1 day ago
FACET monitorName
ORDER BY average(executionDuration) DESC

Find monitors with Chrome tab crashes:

SELECT count(*)
FROM SyntheticCheck
WHERE error LIKE '%tab crashed%'
SINCE 1 day ago
FACET monitorName

Resource recommendations

Based on testing with rc1.15 runtimes:

Timeline

Related documentation

• Install the synthetics job manager
• Job manager configuration
• Troubleshooting scripted browser monitors
• Security bulletin NR26-04