Table of Contents
🧭 Overview
When teams start instrumenting services or onboarding new applications into an observability platform, conversations usually get messy fast.
What should we measure? What’s important? What’s “good enough”? The question should be:
How do we improve reliability?
Two proven frameworks cut through that noise: USE and RED.
They approach systems from different angles — one from the infrastructure’s point of view, and the other from the user/service experience. Together, they give you a complete picture of system health.
This article breaks down the differences, when to use each, and how to lead productive dialogues with development and platform teams during instrumentation.
📚 What You’ll Learn
The core differences between the USE and RED metric frameworks
How each framework maps to infrastructure vs. service behavior
How to guide instrumentation discussions with product, dev, and SRE teams
A repeatable process for onboarding new apps into your observability platform
How USE + RED together reduce noise and increase signal
⚙️ What You’ll Need
Access to an observability platform (Grafana, Datadog, New Relic, Prometheus, etc.)
Basic understanding of infrastructure resources
A service or application your team wants to instrument
Willingness to ask clear business- and technical-aligned questions
📊 Understanding the Metric Frameworks
🛠️ USE Method
USE is a resource-first framework. It helps you understand the health and load of the infrastructure powering your systems.
Utilization — How busy a resource is
(CPU%, memory usage, disk I/O consumption)Saturation — How much queued or waiting work exists
(run queue length, backlog, disk queue)Errors — Hardware or system-level errors
(disk errors, network drops, faulty syscalls)
👉 USE helps diagnose why a system might be slow or degraded.
🚦 RED Method
RED is a service-centric framework. It emphasizes what the user experiences when interacting with your service.
Rate — Requests per second
Errors — Failed requests
Duration — How long successful requests take
👉 RED tells you what the service is doing and how well it’s doing it.
🔗 How They Fit Together
| Aspect | USE Method | RED Method |
|---|---|---|
| Focus | Infrastructure | Application/Service |
| Lens | Capacity & bottlenecks | User & request performance |
| Errors Type | Hardware/system failures | Request failures |
| Answers | Why is it slow/broken? | What is the user experiencing? |
They’re not competing frameworks — they’re complementary.
RED highlights symptoms.
USE helps uncover causes.
🧭 Leading the Conversations With Teams
Instrumentation isn’t just about metrics — it’s a conversation.
Here’s how to guide it like a pro.
1️⃣ Start With a Kick-Off
Bring together:
Developers
SRE/DevOps
Product owners
Open with a simple message:
“Our goal is to set up observability so we can detect issues early, reduce alert noise, and improve reliability.”
Then introduce USE + RED so everyone shares a vocabulary.
2️⃣ Define What Success Looks Like
Ask business-level and system-level questions:
For RED (service view):
What does a “successful request” mean?
What latency is acceptable?
Which operations are most critical for users?
For USE (resource view):
What resources does this service depend on?
What’s likely to become a bottleneck under load?
What should trigger an alert before customers feel pain?
You’re creating alignment before writing any instrumentation.
3️⃣ Pick the Actual Metrics
This is where most teams over-collect.
Your job is to help them focus.
RED Metrics to instrument:
Request rate
Request error count
Request duration percentiles (p50, p95, p99)
USE Metrics to instrument:
CPU utilization
Memory utilization
Queue length (saturation)
Disk or network errors
If logging everything is “cheap,” alerting on everything is not.
4️⃣ Build Dashboards With a Story
A good observability dashboard should answer questions in order:
Is the service failing? (RED)
If so, which resource is the bottleneck? (USE)
What changed? (logs/traces)
You’re building a narrative, not just charts.
5️⃣ Iterate After the First Incidents
Once the service is live:
Review alerts: are they clear or noisy?
Review missing metrics: what did the team wish they had?
Update thresholds: tune them based on real usage
USE + RED become a feedback loop that matures the service.
💬 Helpful Prompts for Team Dialogues
🔹 “What does good performance look like for this service?”
(Leads to RED metrics)
🔹 “What would cause this service to choke under high load?”
(Leads to USE metrics)
🔹 “If something slowed down, where would we look first?”
(Helps prioritize instrumentation)
🔹 “Which alerts are worth waking someone up for?”
(Defines critical vs non-critical observability)
These questions cut through debate and surface real requirements quickly.
🧩 Conclusion
USE and RED aren’t just monitoring frameworks — they’re communication tools.
They give teams a shared structure to define what matters, reduce noise, and build observability that actually supports reliability.
When onboarding new applications, we start every instrumentation conversation with USE + RED because they create clarity, prevent over-instrumentation, and produce dashboards that tell meaningful stories.
Leave a Reply