Synthetic monitoring runs automated, scheduled checks against your applications and endpoints from locations you choose — public locations New Relic operates around the world, or private locations inside your own network. Each monitor performs a real request or user journey at a fixed interval and reports the result, so you catch failures, slowdowns, and broken flows as early as possible.
Because those checks are always running, they provide availability, functionality, and a performance baseline for your applications (both API endpoints and browser journeys). APM and browser monitoring tell you how real traffic behaved, while synthetic monitors tell you whether your critical functionality works as expected at all times, including in regions with little traffic or before a release reaches users.
Sample use cases
New Relic synthetic monitoring spans a spectrum from lightweight uptime pings that cover availability broadly to fully scripted API and browser journeys that exercise your most complex flows. On scripted monitors running from private locations you can go further still, extending the runtime with your own npm modules to check almost anything reachable from your network.
Ping
The most economical check you can run is a scheduled HTTP request confirming an endpoint is online and fast enough. Economical enough to run frequently across hundreds of endpoints, which makes it your foundation for broad availability and uptime reporting. It detects outages, not broken functionality, so treat it as your first signal rather than proof the app works.
To get started, see Add and edit monitors for creating one, and View ping monitor results for reading what it reports.
Scripted API
Uses Node.js with the $http API to chain requests, carry auth and state across steps, and use an assertion on status, payload, and timing. Use it to encode a real business transaction at the service layer, or to watch a third-party dependency you rely on but don't control. On private locations, use require() for your own modules to reach non-HTTP protocols or call model, vector-store, and cloud APIs with your existing SDKs.
To get started, see Write synthetic API tests for building your first script, and Import Node.js modules for extending it with libraries.
Simple browser
Loads your page in a real Chrome or Firefox instance, so the check runs your JavaScript, assets, CDN, and cache, rather than just the status code. Catches render-blocking script errors, missing bundles, and silently failing third-party tags that a ping never sees. No code required, so it's the fastest way to get real-render coverage across many pages.
To get started, see Add and edit monitors for creating one, and Device emulation for testing mobile and tablet viewports.
Scripted browser
Drives a real browser with the $browser API (Selenium WebDriver) through multi-step, conditional, authenticated journeys. One check validates the whole path from browser to data layer, such as sign-in, search, checkout, or a critical internal flow. It's the slowest and most resource-intensive monitor, so reserve it for the journeys that carry revenue and trust.
To get started, see Introduction to scripted browser monitors for the basics, and the scripted browser reference for the full $browser API.
Scripted API and scripted browser monitors run your JavaScript, so you can use require() on your own npm modules. You power the protocol, cloud-SDK, and document checks above the same way. On private locations, those modules install from your own registry and run inside your network. Store any keys or tokens as secure credentials.
Custom code and extensibility
New Relic scripted monitors aren't fixed-function checkers — they're programs. If you can express it in code, you can monitor it. That means you can chain custom logic, query your own New Relic data, and extend monitors with your own code and modules.
Bring your own code
Scripted monitors let you use require() on your own modules. On private locations, you mount a directory containing a package.json, and the job manager runs npm install at startup, so any npm package or internal library becomes part of your monitor — enough to speak non-HTTP protocols (TCP, WebSocket, MQTT, LDAP, SFTP, SMTP), call cloud-provider SDKs, or decode proprietary formats. Your monitors' reach is the entire package ecosystem plus your own code, not a fixed feature list — so a new need means adding a dependency, not filing a feature request.
Run it privately, inside your network
Because scripted monitors run on the synthetics job manager, you can execute them from private locations inside your own network. That means exercising internal systems with your own modules, installed from your own registry, without exposing anything to the public internet.
Get alerted on telemetry anomalies
A scripted API monitor can query your own New Relic data and alert on the result based on the logic you define in the custom scripts, providing coverage for scenarios that don't fit within alert conditions like querying data over a longer period of time or comparing results with a previous time period:
- Query your data: Call the NerdGraph API with
$http, using an API key stored as a secure credential, to run a NRQL query. - Alert on deviations: Use an
assertionor similar logic to fail the check when the result crosses a threshold or deviates from a prior period.