New Relic Workloads: Group Entities for Health Views (2026)

Workloads are New Relic’s way of letting you group related entities together, so you can see the overall health of a service or application, rather than just individual components.

Let’s see it in action. Imagine you have a typical web application stack: a frontend Nginx server, a backend Java application running on Tomcat, and a PostgreSQL database.

# /etc/nginx/nginx.conf
server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://localhost:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

// src/main/java/com/example/MyWebApp.java (Simplified Tomcat App)
@WebServlet("/")
public class MyWebApp extends HttpServlet {
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        response.setContentType("text/plain");
        PrintWriter out = response.getWriter();
        out.println("Hello from the backend!");
        // In a real app, this would interact with the DB
    }
}

-- PostgreSQL schema (simplified)
CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    username VARCHAR(50)
);

In New Relic, each of these would typically show up as separate entities: an "Nginx" host, a "Java" process, and a "PostgreSQL" database. This is fine for deep dives into that specific component, but it doesn’t tell you if your entire application is healthy. Did Nginx fail? Is the Java app slow? Is the database overloaded?

This is where Workloads come in. You create a Workload, give it a name (e.g., "MyWebApp Production"), and then define rules to automatically add entities to it.

Here’s how you’d define a Workload in New Relic using the UI, or programmatically via the API. You’d go to "Workloads" > "Create workload".

You can define it based on:

• Entity Name: name = 'your-app-frontend-host'
• Entity Type: type = 'PROCESS_HOST'
• Account ID: accountId = 12345
• Tags: tags.environment = 'production' AND tags.service = 'mywebapp'

So, for our example, you might create rules like:

1. Add all entities where entity.type = 'PROCESS_HOST' AND tags.service = 'mywebapp'. (This would catch your Nginx host).
2. Add all entities where entity.type = 'APM' AND tags.service = 'mywebapp'. (This would catch your Java application).
3. Add all entities where entity.type = 'DATABSE' AND tags.service = 'mywebapp'. (This would catch your PostgreSQL instance).

Once these entities are grouped into the "MyWebApp Production" Workload, you get a single dashboard. This dashboard shows a consolidated health status. If Nginx is down, or the Java app is throwing errors, or the database is spiking in CPU, the Workload health indicator will reflect that. You can then drill down into the Workload to see which specific component is the culprit.

The core problem Workloads solve is information overload and the lack of a unified "service health" view. Instead of monitoring dozens or hundreds of individual entities, you monitor a curated set that represents a functional unit. This allows for faster incident response because you’re looking at the business impact, not just the technical component.

The surprising thing is how granular you can get with the rules. You’re not just limited to basic entity types. You can reference specific alert conditions, custom attributes, and even other Workloads to build complex, nested views. For example, you could have a "MyWebApp Production" Workload that includes a "MyWebApp Database" Workload, allowing you to aggregate at multiple levels of abstraction.

The next concept to explore is how to automate Workload creation and management, especially in dynamic cloud environments.