---
title: Synthetic monitoring use cases
source: https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/guides/synthetic-monitoring-use-cases
---

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](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/guides/private-location-capabilities/) 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 [#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 [#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.

**See example use cases**

Common checks:

-   **Endpoint reachable:** Send a request on a schedule and confirm it returns a healthy status code (a 200, or any 2xx or 3xx), with no auth or scripting.
-   **Response-time threshold:** Fail the check when the endpoint responds slower than your threshold, so latency regressions alert you early.
-   **Body string-match:** Pass only when the response body contains an expected string, such as `ok` or `"status":"healthy"`.

To get started, see [Add and edit monitors](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/using-monitors/add-edit-monitors/) for creating one, and [View ping monitor results](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/using-monitors/view-ping-monitor-results/) for reading what it reports.

### Scripted API [#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.

**See example use cases**

Common checks:

-   **Network and protocol:** Open a non-HTTP connection and use `assert` to ensure that it succeeds. Confirm a TCP or TLS port is open, resolve a DNS record, exchange WebSocket or MQTT messages, or reach LDAP, FTP/SFTP, and SMTP.
-   **Certificates and security:** Call an API with a client certificate (mutual TLS) and use `assert` to ensure that it authenticates, validate the certificate embedded in SAML metadata, or check your mail IPs against blocklists.
-   **Cloud and SaaS integration:** Authenticate to AWS, Azure, or GCP and use `assert` to ensure that a resource is present, for example, confirm an S3 export object exists or read an Azure Key Vault secret.
-   **Performance and SEO:** Run a Lighthouse audit through the PageSpeed API and record the scores, or pull Search Console metrics on a schedule.
-   **New Relic data (NRDB/NRQL):** Run a NRQL query from the monitor and alert when the result crosses a threshold or deviates from a prior period.

To get started, see [Write synthetic API tests](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/scripting-monitors/write-synthetic-api-tests/) for building your first script, and [Import Node.js modules](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/scripting-monitors/import-nodejs-modules/) for extending it with libraries.

### Simple browser [#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.

**See example use cases**

Common checks:

-   **Page availability:** Open the page from global locations and confirm it loads and renders the expected content.
-   **Content and element checks:** Use `assert` to ensure that a specific element or text is present, such as the "Add to cart" button on a product page.
-   **Core Web Vitals:** Measure page-load time and fail the check when it exceeds your budget, for example 3 seconds.

To get started, see [Add and edit monitors](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/using-monitors/add-edit-monitors/) for creating one, and [Device emulation](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/using-monitors/device-emulation/) for testing mobile and tablet viewports.

### Scripted browser [#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.

**See example use cases**

Common checks:

-   **Browser UX and content:** Drive the page to crawl its links and fail on any broken one, time a file download, or verify the text inside a downloaded PDF.
-   **Cloud and SaaS integration:** Capture screenshots during the journey and upload them to cloud storage such as S3.

To get started, see [Introduction to scripted browser monitors](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/scripting-monitors/introduction-scripted-browser-monitors/) for the basics, and the [scripted browser reference](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/scripting-monitors/synthetic-scripted-browser-reference-monitor-versions-chrome-100/) 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](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/using-monitors/store-secure-credentials-scripted-browsers-api-tests/).

## Custom code and extensibility [#programmable-monitoring]

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 [#bring-your-own-code]

Scripted monitors let you use `require()` on your own modules. On [private locations](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/guides/private-location-capabilities/), 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 [#run-privately]

Because scripted monitors run on the synthetics job manager, you can execute them from [private locations](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/guides/private-location-capabilities/) 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 [#monitor-telemetry]

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`](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/scripting-monitors/write-synthetic-api-tests/#get-nerdgraph-example), using an API key stored as a [secure credential](https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/using-monitors/store-secure-credentials-scripted-browsers-api-tests/), to run a NRQL query.
-   **Alert on deviations:** Use an `assertion` or similar logic to fail the check when the result crosses a threshold or deviates from a prior period.