RED vs USE: Two Monitoring Frameworks Explained

If you're building observability into your applications, you've likely heard both the RED method and USE method mentioned. Understanding the difference between the RED method vs USE method monitoring frameworks is crucial: they measure different layers of your system and answer different operational questions. RED focuses on application behavior; USE focuses on infrastructure health. Both matter, but they're not interchangeable, and conflating them often leads to blind spots in production.

The RED and USE frameworks were developed to give operators a methodical way to instrument their systems. RED came from Brendan Gregg, designed for application-level monitoring. USE (Utilization, Saturation, Errors) also from Brendan Gregg, was born from infrastructure and kernel-level troubleshooting. Knowing which to apply—and when—makes the difference between fast incident resolution and hours of guesswork.

What Is the RED Method?

RED stands for Rate, Errors, Duration. It's a framework for monitoring user-facing services and APIs.

• Rate: How many requests per second is your service handling? This is throughput—typically requests/sec or events/sec.
• Errors: How many of those requests failed? This includes HTTP 5xx errors, timeouts, exceptions, and any other failure condition.
• Duration: How long does each request take? Measure p50, p99, and max latency to understand the full distribution.

RED is inherently an application-level view. You're asking: "Is my service healthy from the user's perspective?" A healthy RED profile shows steady rate, low error count, and consistent, acceptable latencies. When any of these degrade, users feel it directly.

What Is the USE Method?

USE stands for Utilization, Saturation, Errors. It's a framework for monitoring infrastructure—servers, containers, databases, and the resources they consume.

• Utilization: What percentage of a resource's capacity is in use? CPU %, memory %, disk I/O, network bandwidth.
• Saturation: Is the resource overloaded? Queue depth, run queue length, wait time for I/O.
• Errors: Hardware errors, memory allocation failures, dropped packets—resource-level faults.

USE is the infrastructure questionnaire. You're asking: "Do I have enough capacity?" A healthy USE profile shows utilization well below ceiling, saturation near zero, and no resource errors. When utilization climbs or saturation rises, the system will slow down and fail if not provisioned correctly.

RED for Applications, USE for Infrastructure

The key insight is domain separation. RED applies to application code and user-facing services. USE applies to the box running that code—CPU, RAM, disk, network.

A system can have a healthy RED profile and failing USE profile simultaneously. Your API might handle requests at a steady rate with low errors and fast p95 latencies, yet the database it depends on could be at 95% CPU utilization with a massive IO queue. Users experience slowness; RED looks fine; USE shows the real problem.

Conversely, a system can have poor RED and excellent USE. A misconfigured load balancer might spray traffic unevenly, causing one instance to be completely saturated while others sit idle. Individual infrastructure metrics look reasonable; RED exposes the imbalance.

When to Apply RED: Application Monitoring

Use RED when you're instrumenting:

• Web APIs and microservices: Capture request count, error rate, and latency per endpoint.
• Background jobs and message queues: Track job count, failure rate, and execution time.
• User-facing features: Monitor feature adoption, error rates, and response times.

RED is upstream of error tracking best practices. Error tracking tells you what broke and why; RED tells you the aggregate impact on users. If your error rate spikes, RED makes that visible before users report it. Combined with detailed error grouping and stack traces, RED metrics plus error data let you quickly prioritize error triage and reduce MTTR.

Distributed tracing fits neatly into RED monitoring as well. When you see p99 latency spike, you can drill into a span waterfall to see which service in the chain is slow. RED identifies the problem; tracing tells you where in the system it lives.

When to Apply USE: Infrastructure Monitoring

Use USE when you're watching:

• Servers and VMs: CPU, memory, disk, and network utilization plus saturation metrics.
• Container orchestration: Pod resource requests/limits, node capacity, eviction pressure.
• Databases: Connection pool saturation, query queue depth, buffer cache hit rate, disk I/O wait.
• Load balancers and routers: Connection table saturation, dropped packets, queue backlog.

USE is your health checks foundation. When USE metrics show a resource nearing saturation, you know a spike or cascading failure is possible. USE metrics inform capacity planning and alert thresholds; they're often fed into autoscaling rules.

How RED and USE Complement Each Other

The best observability strategy uses both. Here's a concrete example:

Your e-commerce API has steady request rate (RED: ~100 req/s), error rate under 1% (RED: good), and p99 latency at 400ms (RED: acceptable for checkout). But your database server CPU is at 92% utilization (USE: high) with a 50-query queue (USE: saturated). You're still serving customers, but you're one traffic spike away from failures. RED alone would tell you everything is fine; USE reveals the brittleness.

Conversely, RED catches problems USE cannot. If a single endpoint has a memory leak and is leaking 10MB per request, your server's overall memory utilization (USE) might stay reasonable for hours—until it suddenly isn't. But RED latency on that endpoint degrades linearly with every request, alerting you much earlier.

Monitoring RED in LightTrace

LightTrace tracks RED metrics natively for any Sentry SDK. Point your SDK (Node, Python, Go, Java—unmodified) at LightTrace by changing only the DSN, and RED data flows automatically:

// Next.js / Node app
import * as Sentry from "@sentry/node";

Sentry.init({
  dsn: "https://<key>@light-trace.robomiri.com/1",
  integrations: [
    new Sentry.Integrations.Http({ tracing: true }),
  ],
  tracesSampleRate: 0.1, // 10% of requests
});

LightTrace captures request throughput per endpoint, error rates by status code, and latency percentiles. You also get full stack traces for every error, breadcrumbs showing what led to failure, and distributed tracing across service boundaries. When RED metrics spike, you drill into the actual errors, see affected users, and link directly to the offending code on GitHub.

Choosing Your Instrumentation Strategy

Start with RED if you're building an application from scratch. RED is simpler to instrument (often automatic with middleware) and directly relevant to user experience. As you grow, layer in USE metrics from infrastructure tools to catch resource bottlenecks before RED degrades. For preventing cascading failures, understanding both is essential: RED tells you which service is failing; USE tells you if you have capacity to degrade gracefully.

If you inherit a system with neither, begin with RED. Application health is upstream of infrastructure health—a broken service is broken regardless of available capacity. Once RED is solid, instrument USE to prevent avoidable resource exhaustion and to handle external dependency failures with confidence.