New Relic¶

New Relic is a comprehensive observability platform that helps developers, operations teams, and businesses monitor the performance of their applications and infrastructure in real-time. It provides detailed insights into application performance, error tracking, and user experience, enabling teams to identify and resolve issues quickly and maintain high availability of their services.

The New Relic application allows you to retrieve the status of New Relic services and check their availability. Status information can be visualized from the New Relic Status website.

Options

Name*: Just a simple label to find it easier in the SenHub's interface
Description: Description for your own usage only.
Vault*: Choose in the list box the appropriate vault for this resource. If you have not created it yet, see how to add a vault.
Group: optional — assign this instance to a group to organise it within SenHub.
Area*: You have to choose from where you want to collect the metrics. The options are:
- EU — Only return Europe/Middle East/Africa instances status.
- US — Only return North America instances status.
Representation*: You can get 7 types of metrics, each providing a different angle on your synthetic monitor's behavior. The options are:
- By location — Gives you a complete health overview of your synthetic monitor: overall success rate, number of failed checks and failing locations, performance quality indicators (Apdex, SLA breakdown), response time distribution (percentiles), and the latest response time from each geographic location. This is the go-to mode for a global dashboard view.
- Network timings — Breaks down the network phases of your synthetic requests (DNS resolution, TCP connection, SSL handshake, sending, waiting for server response, receiving). Use this when you need to understand where the time is being spent in the network layer — for example, to identify if a slow response is due to a distant DNS, a heavy SSL handshake, or a slow backend.
- Monitor results — Extracts the custom step-by-step metrics you've defined in your synthetic browser scripts (e.g., login time, search time, checkout time), along with the total execution time and the technical result (success or failure). When a scenario fails, the error message is included so you can immediately understand what went wrong. Perfect for tracking business-critical user journeys.
- Request analysis — Analyzes all individual HTTP requests made during your synthetic checks: how many requests, how much data was downloaded, which domains were called, how fast each responded, and which returned errors (4xx, 5xx). Use this to detect third-party dependency slowdowns, unexpected page weight increases, or broken resources.
- Private location — Monitors the health of your New Relic private locations (the on-premise infrastructure that runs your synthetic checks). Tracks the pending-check queue and the ping / minion / job-manager job counters per location, plus the freshness of the last status report. Only applicable to accounts using private synthetic locations.
- Trend — Compares today's performance against a same-weekday baseline: average duration, success rate, and p95 duration, each with the delta showing improvement or degradation. Use this to quickly spot regressions after a deployment or confirm that an optimization had the expected impact.
- Uptime — Reports availability over rolling windows (24h / 7 days / 30 days) plus the number of failed checks and an estimated downtime over 30 days. This is the mode that feeds SLA reporting and answers "how available has this service been this month?".
Monitor Name*: By going to the New Relic interface, you can copy and paste the name of your monitor as is into this field. The name is case-sensitive.
Verbose mode (optional): Enable detailed debug output to troubleshoot connection or data retrieval issues.

By Location¶

The By Location mode provides a complete health overview of your synthetic monitor from each configured location.

Returned metrics explained

Metric	What it tells you
Monitor status	Whether the monitor is currently enabled, disabled, or muted in New Relic
Monitor status code	Numeric mirror of the status (1 = enabled, 2 = disabled, 3 = muted, 0 = unknown) so it can be alarmed in PRTG via the `sfs.newrelic.synthetics` lookup — a text channel cannot carry a threshold
Last 7.5h success rate	Percentage of successful checks over the last 7.5 hours — a quick reliability indicator
Last 7.5h Checks failed	Total number of failed checks in that period — helps assess the severity of an issue
Locations failing	Number of distinct geographic locations currently experiencing failures — if all locations fail, the problem is likely on the target side; if only one fails, it may be a network or location-specific issue
Apdex (24h)	Application Performance Index over 24 hours (scale 0 to 1), computed against the monitor's own Apdex target (7 seconds by default). Above 0.85 is generally considered satisfactory. Gives a single number to assess user experience quality
Satisfied / Tolerating / Frustrated (24h)	SLA breakdown against the Apdex target T: percentage of checks completed under T (satisfied), between T and 4×T (tolerating), or over 4×T (frustrated). With the default 7 s target that is under 7 s / 7–28 s / over 28 s. Shows the distribution of user experience, not just the average
p50 / p90 / p95 / p99 duration (24h)	Response time percentiles over 24 hours. The p50 is the median, the p95 tells you what 95% of users experience. A large gap between p50 and p99 indicates inconsistent performance
{Location name}	Latest response time (ms) from each geographic location — lets you compare regional performance at a glance
Last check age	Minutes since the most recent check. A watchdog: if New Relic or the private location stops producing checks, every other metric keeps its last value and stays green — this one climbs instead. Set a PRTG threshold at roughly 3× the monitor's check period

Example Output for By Location

[
  {
    "channel": "Monitor status",
    "value": "Enabled"
  },
  {
    "channel": "Monitor status code",
    "value": 1
  },
  {
    "channel": "Last 7.5h success rate",
    "value": 100.0,
    "unit": "%"
  },
  {
    "channel": "Last 7.5h Checks failed",
    "value": 0,
    "unit": "#"
  },
  {
    "channel": "Locations failing",
    "value": 0,
    "unit": "#"
  },
  {
    "channel": "Apdex (24h)",
    "value": 0.86
  },
  {
    "channel": "Satisfied (24h)",
    "value": 72.92,
    "unit": "%"
  },
  {
    "channel": "Tolerating (24h)",
    "value": 27.08,
    "unit": "%"
  },
  {
    "channel": "Frustrated (24h)",
    "value": 0.0,
    "unit": "%"
  },
  {
    "channel": "p50 duration (24h)",
    "value": 6288,
    "unit": "ms"
  },
  {
    "channel": "p90 duration (24h)",
    "value": 8048,
    "unit": "ms"
  },
  {
    "channel": "p95 duration (24h)",
    "value": 9248,
    "unit": "ms"
  },
  {
    "channel": "p99 duration (24h)",
    "value": 12844,
    "unit": "ms"
  },
  {
    "channel": "Paris",
    "value": 6059,
    "unit": "ms"
  },
  {
    "channel": "Last check age",
    "value": 13.7,
    "unit": "min"
  }
]

Network Timings¶

The Network Timings mode breaks down the network phases of your synthetic requests to pinpoint bottlenecks.

Returned metrics explained

Metric	What it tells you
DNS	Time to resolve the domain name. High values may indicate DNS server issues or missing DNS caching
Connect	Time to establish the TCP connection. High values suggest network latency between the monitor location and the target server
SSL	Time for the SSL/TLS handshake. High values may point to certificate chain issues or an overloaded server
Send	Time to transmit the HTTP request. Usually very small; high values indicate upstream bandwidth issues
Wait	Time waiting for the first byte of the server response (TTFB). This is often the largest value and reflects backend processing time
Receive	Time to download the full response. High values indicate large payloads or slow transfer rates
Block	Time the request spent queued before it could be sent. High values suggest too many concurrent connections or resource contention

Example Output for Network Timings

[
  {
    "channel": "Monitor status",
    "value": "Enabled"
  },
  {
    "channel": "Monitor status code",
    "value": 1
  },
  {
    "channel": "DNS",
    "value": 0.028,
    "unit": "ms"
  },
  {
    "channel": "Connect",
    "value": 0.774,
    "unit": "ms"
  },
  {
    "channel": "SSL",
    "value": 0.604,
    "unit": "ms"
  },
  {
    "channel": "Send",
    "value": 0.129,
    "unit": "ms"
  },
  {
    "channel": "Wait",
    "value": 13.46,
    "unit": "ms"
  },
  {
    "channel": "Receive",
    "value": 7.34,
    "unit": "ms"
  },
  {
    "channel": "Block",
    "value": 26.625,
    "unit": "ms"
  }
]

Monitor Results¶

The Monitor Results mode extracts the custom metrics you've defined in your New Relic synthetic browser scripts, giving you visibility on each step of your user scenario.

Returned metrics explained

Metric	What it tells you
01_stepName, 02_stepName, ...	Execution time (ms) of each numbered step in your scenario — lets you see exactly which part of the user journey is slow
Total_time	Total scenario execution time (ms) — the sum of all steps, representing the full user journey duration
Error	When the scenario fails: the error message from New Relic describing what went wrong (e.g., element not found, timeout). Only appears when the result is FAILED
Result	Technical outcome of the scenario: 1 = SUCCESS, 0 = FAILED. Uses the PRTG lookup `sfs.newrelic.monitoringresult` for visual status mapping

Each metric is suffixed with the location name (e.g., "01_firstPage (paris)") so you can monitor performance from each geographic location independently.

How to set up your synthetic script

In your New Relic synthetic browser script, define custom metrics using:

$browser.addPageAction('custom.01_firstPage', loadTime);
$browser.addPageAction('custom.02_authentication', authTime);
$browser.addPageAction('custom.total_time', totalTime);

The connector will automatically extract all custom.* fields and present them in order.

Example Output for Monitor Results (success)

[
  {
    "channel": "01_firstPage (paris)",
    "value": 1419,
    "unit": "ms"
  },
  {
    "channel": "02_authentication (paris)",
    "value": 1404,
    "unit": "ms"
  },
  {
    "channel": "03_search (paris)",
    "value": 2727,
    "unit": "ms"
  },
  {
    "channel": "Total_time (paris)",
    "value": 5550,
    "unit": "ms"
  },
  {
    "channel": "Result (paris)",
    "value": 1
  }
]

Example Output for Monitor Results (failure)

When a scenario fails, the custom step metrics may be absent (the script crashed before recording them). The error message is automatically extracted and truncated to 200 characters for readability.

[
  {
    "channel": "Error (paris)",
    "value": "no such element: Unable to locate element: {\"method\":\"css selector\",\"selector\":\"*[id=\\\"LoginButton\\\"]\"}"
  },
  {
    "channel": "Result (paris)",
    "value": 0
  }
]

Request Analysis¶

The Request Analysis mode examines all individual HTTP requests made during your synthetic checks, helping you understand what happens under the hood of your scenarios.

Returned metrics explained

Metric	What it tells you
Total requests	Number of HTTP requests made during the check — a sudden increase may indicate new resources being loaded or redirect chains
Total download	Total data downloaded (KB) — helps detect page weight regressions
Avg request duration	Average time per request (ms) — a global indicator of resource loading speed
Main page duration	Average load time of the main navigation request only — isolates the primary page performance from sub-resources
Sub-resource avg duration	Average load time of all other requests (scripts, images, fonts, APIs) — helps identify if slowness comes from the page itself or its dependencies
Avg request / response body size	Average payload sizes (bytes) — useful for detecting unexpected payload increases
Avg request / response header size	Average header sizes (bytes) — helps spot oversized cookies or header bloat
HTTP {code} errors	Number of requests that returned a 4xx or 5xx status code, grouped by observed code — reveals broken resources (404), unauthorized calls (401), or server errors (500). These channels are dynamic: they only appear while an error is present
{domain} avg / count	Average response time and request count for the top 10 domains called — lets you identify slow third-party dependencies (CDN, analytics, APIs)
HTTP 4xx errors / HTTP 5xx errors	Aggregate client-error and server-error counts. Unlike the dynamic per-code channels above, these are always emitted, so you can set a permanent PRTG threshold on them
Error rate	Percentage of requests that returned an error (status ≥ 400) — a single always-present number to alarm on
Main page TTFB	Time to first byte of the main navigation request (ms) — isolates backend response time from the rest of page loading
Page load / DOM content loaded	Time (ms) for the main page's `load` and `DOMContentLoaded` events — the browser-perceived page readiness

Example Output for Request Analysis

[
  {
    "channel": "Total requests",
    "value": 406,
    "unit": "#"
  },
  {
    "channel": "Total download",
    "value": 42282.1,
    "unit": "KB"
  },
  {
    "channel": "Avg request duration",
    "value": 48.4,
    "unit": "ms"
  },
  {
    "channel": "Main page duration",
    "value": 44.7,
    "unit": "ms"
  },
  {
    "channel": "Sub-resource avg duration",
    "value": 48.4,
    "unit": "ms"
  },
  {
    "channel": "Avg request body size",
    "value": 214,
    "unit": "bytes"
  },
  {
    "channel": "Avg response body size",
    "value": 106643,
    "unit": "bytes"
  },
  {
    "channel": "HTTP 404 errors",
    "value": 4,
    "unit": "#"
  },
  {
    "channel": "HTTP 401 errors",
    "value": 2,
    "unit": "#"
  },
  {
    "channel": "xtremcloud.cloud avg",
    "value": 48.8,
    "unit": "ms"
  },
  {
    "channel": "xtremcloud.cloud count",
    "value": 402,
    "unit": "#"
  },
  {
    "channel": "HTTP 4xx errors",
    "value": 6,
    "unit": "#"
  },
  {
    "channel": "HTTP 5xx errors",
    "value": 0,
    "unit": "#"
  },
  {
    "channel": "Error rate",
    "value": 3.32,
    "unit": "%"
  },
  {
    "channel": "Main page TTFB",
    "value": 17.1,
    "unit": "ms"
  },
  {
    "channel": "Page load",
    "value": 1712,
    "unit": "ms"
  },
  {
    "channel": "DOM content loaded",
    "value": 1269.3,
    "unit": "ms"
  },
  {
    "channel": "Avg request header size",
    "value": 1477,
    "unit": "bytes"
  },
  {
    "channel": "Avg response header size",
    "value": 347,
    "unit": "bytes"
  }
]

Private Location¶

The Private Location mode monitors the health of your New Relic private locations — the on-premise infrastructure running your synthetic checks.

Note: This mode is only applicable to accounts using New Relic private synthetic locations. It reads the current SyntheticsPrivateLocationStatus event; the older host-level minion metrics (CPU, memory, workers) are no longer published by New Relic and are not available.

Returned metrics explained

Metric	What it tells you
Checks pending	Number of checks waiting to be executed by the location — a growing backlog means the location cannot keep up with the check schedule
Ping jobs	Number of lightweight ping checks queued for the location
Minion heavyweight jobs	Number of heavyweight (scripted / browser) jobs queued on the minion runtime
Job manager heavyweight jobs	Number of heavyweight jobs queued on the job-manager runtime (containerized private locations)
Status age	Minutes since the location last reported its status. A watchdog: a dead private location simply drops out of New Relic's reporting, freezing its other metrics green — this one climbs instead

Each metric is suffixed with the private location name (e.g., "Checks pending (4284882-lna1-620)").

Example Output for Private Location

[
  {
    "channel": "Checks pending (4284882-lna1-620)",
    "value": 0,
    "unit": "#"
  },
  {
    "channel": "Ping jobs (4284882-lna1-620)",
    "value": 0,
    "unit": "#"
  },
  {
    "channel": "Minion heavyweight jobs (4284882-lna1-620)",
    "value": 0,
    "unit": "#"
  },
  {
    "channel": "Job manager heavyweight jobs (4284882-lna1-620)",
    "value": 0,
    "unit": "#"
  },
  {
    "channel": "Status age (4284882-lna1-620)",
    "value": 1.0,
    "unit": "min"
  }
]

Trend¶

The Trend mode compares today against a same-weekday baseline to help you spot performance changes over time.

The (1w ago) baseline is not a single noisy day: it is the median of the last four same weekdays (a Tuesday is compared to the four previous Tuesdays), which neutralises weekly seasonality and absorbs a one-off bad day. Duration and p95 are measured over successful checks only, so a day with failures (which run slower) does not inflate the baseline and mask a real regression. The success rate itself is still computed over all checks.

Returned metrics explained

Metric	What it tells you
Avg duration (today)	Average duration of successful checks over the last 24 hours
Avg duration (1w ago)	Baseline average duration: median of the last four same weekdays (successful checks)
Duration delta	Difference in milliseconds. Negative = faster (improvement), positive = slower (degradation)
Success rate (today)	Percentage of successful checks over the last 24 hours
Success rate (1w ago)	Baseline success rate: median of the last four same weekdays
Success rate delta	Difference in percentage points. Negative = fewer successes (degradation), positive = more successes (improvement)
p95 duration (today)	95th percentile duration of successful checks over the last 24 hours — what 95% of your checks complete within
p95 duration (1w ago)	Baseline p95: median of the last four same weekdays (successful checks)
p95 delta	Difference in milliseconds. Negative = improvement, positive = degradation

Use this mode after a deployment or infrastructure change to validate that performance hasn't regressed, or to confirm that an optimization had the expected effect.

Example Output for Trend

[
  {
    "channel": "Avg duration (today)",
    "value": 6729,
    "unit": "ms"
  },
  {
    "channel": "Avg duration (1w ago)",
    "value": 7749,
    "unit": "ms"
  },
  {
    "channel": "Duration delta",
    "value": -1020,
    "unit": "ms"
  },
  {
    "channel": "Success rate (today)",
    "value": 100.0,
    "unit": "%"
  },
  {
    "channel": "Success rate (1w ago)",
    "value": 100.0,
    "unit": "%"
  },
  {
    "channel": "Success rate delta",
    "value": 0.0,
    "unit": "%"
  },
  {
    "channel": "p95 duration (today)",
    "value": 9248,
    "unit": "ms"
  },
  {
    "channel": "p95 duration (1w ago)",
    "value": 14016,
    "unit": "ms"
  },
  {
    "channel": "p95 delta",
    "value": -4768,
    "unit": "ms"
  }
]

Uptime¶

The Uptime mode reports availability over rolling windows and an estimated downtime — the data that feeds SLA reporting. Where the other modes only look at the last few hours, this one answers "how available has this service been today, this week, this month?".

Returned metrics explained

Metric	What it tells you
Uptime (24h) / (7d) / (30d)	Percentage of successful checks over the last 24 hours, 7 days and 30 days — your availability figures over the usual SLA windows
Total checks (30d)	Number of checks run over 30 days — the sample size behind the 30-day uptime
Failed checks (30d)	Number of failed checks over 30 days
Downtime estimate (30d)	Estimated downtime in minutes over 30 days, computed as failed checks × the monitor's check period. An approximation (it assumes each failed check covers one period), handy for an at-a-glance SLA figure

Example Output for Uptime

[
  {
    "channel": "Uptime (24h)",
    "value": 100.0,
    "unit": "%"
  },
  {
    "channel": "Uptime (7d)",
    "value": 100.0,
    "unit": "%"
  },
  {
    "channel": "Uptime (30d)",
    "value": 99.132,
    "unit": "%"
  },
  {
    "channel": "Total checks (30d)",
    "value": 2880,
    "unit": "#"
  },
  {
    "channel": "Failed checks (30d)",
    "value": 25,
    "unit": "#"
  },
  {
    "channel": "Downtime estimate (30d)",
    "value": 375,
    "unit": "min"
  }
]