New Relic for Beginners: What Observability Actually Means and How to Start

Most engineering teams know they need monitoring. Fewer understand what observability actually means — and why the distinction matters when something breaks at 2am.

This guide walks you through the foundational concepts and gives you a practical starting point with New Relic.

Monitoring vs. Observability

Monitoring tells you when something is wrong. A CPU alert fires. A service goes down. An error rate crosses a threshold. Monitoring answers: is the system healthy?

Observability tells you why something is wrong. It gives you the ability to ask arbitrary questions about system behavior — from the outside — without having to deploy new instrumentation every time you hit an unknown failure mode.

The three pillars of observability are:

  • Metrics — numeric measurements over time (response time, error rate, throughput)
  • Traces — end-to-end records of individual requests as they travel through distributed systems
  • Logs — timestamped records of events inside your application

New Relic unifies all three in a single platform, with a common query language (NRQL) that works across all data types.

Your First New Relic Setup

Step 1: Create an Account and Note Your Account ID

Sign up at newrelic.com. Your Account ID is visible in the URL when you are logged in — you will need it for agent configuration. Write it down.

Step 2: Install the APM Agent

APM (Application Performance Monitoring) is where most teams start. New Relic provides agents for Node.js, Java, Python, .NET, Ruby, PHP, and Go.

For a Node.js application:

npm install newrelic --save

Then create newrelic.js in your project root:

exports.config = {
  app_name: ['Your App Name'],
  license_key: 'YOUR_LICENSE_KEY',
  logging: {
    level: 'info',
  },
};

Require it as the first line of your application entry point:

require('newrelic');

Within minutes of deploying, New Relic begins collecting response times, throughput, error rates, and transaction traces — with zero additional code.

Step 3: Explore the APM Summary

In the New Relic UI, navigate to APM & Services and select your application. The summary view shows:

  • Web transaction time — how long your endpoints take on average
  • Throughput — requests per minute
  • Error rate — percentage of requests resulting in errors
  • Apdex score — a satisfaction metric combining response time thresholds

The transactions view shows which specific endpoints are slowest. This is usually where you find your first actionable insight.

Understanding NRQL

NRQL (New Relic Query Language) is SQL-like and used to query all New Relic data. You do not need to master it immediately, but understanding the basics makes every other part of the platform more useful.

The basic structure:

SELECT <attribute> FROM <data type> WHERE <condition> SINCE <time range>

Examples:

-- Average response time for the last hour
SELECT average(duration) FROM Transaction SINCE 1 hour ago

-- Error rate by endpoint
SELECT percentage(count(*), WHERE error IS true)
FROM Transaction FACET name SINCE 30 minutes ago

-- Count of a specific log pattern
SELECT count(*) FROM Log WHERE message LIKE '%timeout%' SINCE 1 day ago

NRQL results can be visualized as line charts, bar charts, tables, or billboard values — and saved to dashboards.

Setting Up Your First Alert

An alert in New Relic has three parts:

  1. Alert policy — the container (one per team or service is a good starting point)
  2. Alert condition — the NRQL query + threshold that triggers an alert
  3. Notification channel — where alerts go (email, Slack, PagerDuty, etc.)

A simple error rate alert:

SELECT percentage(count(*), WHERE error IS true)
FROM Transaction
WHERE appName = 'Your App Name'

Set the critical threshold to trigger when this value exceeds 5% for at least 5 minutes. This prevents alert storms from transient spikes.

What to Instrument Next

Once APM is running and your first alerts are in place:

  • Browser monitoring — instrument your frontend to track real user experience, not just server-side performance
  • Synthetic monitoring — set up scripted checks that simulate user journeys and alert before real users are affected
  • Infrastructure monitoring — install the infrastructure agent on your servers or containers to track CPU, memory, disk, and network
  • Log management — forward your application and system logs to New Relic for correlation with metrics and traces

Observability is not a one-time setup. It is a habit of instrumenting what you care about before it breaks — not after.

Arivanandhan Chitheshwaran