New Relic Synthetics monitors aren’t just black boxes that ping your endpoints; they’re actually running full browser instances or making actual API calls from a global network of locations.
Let’s watch a Script Browser monitor in action. Imagine you’re on example.com.
// In New Relic Synthetics Script Browser monitor
$browser.get("https://example.com");
$browser.waitForAndFindElement(By.id("main-content")).then(function(element) {
console.log("Found main content element!");
return element.getText();
}).then(function(text) {
console.log("Main content text:", text.substring(0, 50) + "..."); // Log first 50 chars
$browser.takeScreenshot();
});
This script tells a real browser, running in a New Relic location, to load example.com. It then waits for an element with id="main-content", logs its text, and takes a screenshot. If any of these steps fail (e.g., the page doesn’t load, the element isn’t found within the timeout, or the script itself has a JavaScript error), the monitor fails, and you get an alert.
How it Works Under the Hood
New Relic Synthetics utilizes a fleet of dedicated machines, called "Private Minions" (for on-premises or VPC deployments) or "Public Minions" (for New Relic’s global network), to execute these monitoring scripts.
- Script Browser Monitors: These employ headless browser instances (like Chrome or Firefox) to simulate user interactions. They can navigate websites, click buttons, fill forms, and assert expected outcomes, providing end-to-end user experience monitoring.
- API Monitors: These directly make HTTP requests to your APIs. They are lighter weight than browser monitors and are ideal for checking the availability and performance of your backend services, including REST APIs, SOAP services, and other web endpoints.
The Core Levers You Control
When you set up a monitor, you’re essentially configuring:
- The Target: The URL or API endpoint to test.
- The Type of Test: Script Browser, API, Ping, Simple Browser, etc.
- The Assertion Logic: What conditions must be met for the test to pass (e.g., status code 200, specific text on the page, response time under a threshold).
- The Execution Schedule: How often the test runs.
- The Locations: From which of New Relic’s global network or your Private Minions the test should be executed.
- The Alerting Policy: Who gets notified and how when the monitor fails.
The Mental Model: What’s Actually Happening
Think of each monitor execution as a small, automated user session or an API client request originating from a specific geographic point. The data collected isn’t just a simple UP/DOWN status. It includes detailed timing breakdowns for each step (DNS lookup, connection, SSL, first byte, DOM processing, etc.), screenshots of the page at failure, HAR files for deep request analysis, and console logs from the browser. For API monitors, you get full request/response details, headers, and timing for each phase of the HTTP transaction. This granular data is crucial for pinpointing where and why performance issues or errors are occurring, not just that they are occurring.
The most surprising part for many is how deeply the browser simulation can be controlled. You can use standard WebDriverJS APIs within Script Browser monitors to manipulate cookies, set custom headers for specific requests within the browser context (though this is less common than assertions), and even execute arbitrary JavaScript in the page’s context to fetch data or trigger client-side logic that wouldn’t be visible to a simple HTTP request. This allows for testing complex, JavaScript-heavy applications in a way that truly mimics a user’s experience.
Next Steps
Once you’re comfortable with setting up and interpreting basic Script Browser and API monitors, you’ll want to explore how to chain these monitors together to test multi-step user flows, like a full login and checkout process.