RED Method is a monitoring methodology for request-driven microservices that focuses on three key metrics: Rate (requests per second), Errors (failed requests per second), and Duration (distribution of request latency). Created by Tom Wilkie, the RED method simplifies the golden signals into a practical framework specifically designed for services that handle requests in cloud-native architectures.
Why the RED Method Matters
While the four golden signals provide a comprehensive framework, not every signal is equally relevant for every service. The RED method focuses specifically on the metrics that matter most for request-driven services like APIs, web servers, and microservices. By tracking just three metrics per service, teams can quickly assess health, detect regressions, and identify bottlenecks without drowning in unnecessary data.
Teams that understand and adopt red method gain a significant operational advantage, reducing manual effort and improving the reliability and scalability of their infrastructure. As cloud-native adoption accelerates, familiarity with red method has become a core competency for DevOps engineers, platform teams, and site reliability engineers working in production Kubernetes and cloud environments.
How the RED Method Works
For each service, instrument and track three metrics. Rate is the number of requests per second. Errors is the number of failing requests. Duration is how long requests take, measured at p50, p95, and p99 percentiles. These metrics can be collected using Prometheus with standard HTTP middleware instrumentation or through service mesh telemetry from Istio or Linkerd without application code changes.
Understanding how red method fits into the broader cloud-native ecosystem is important for making informed architecture decisions. It works alongside other tools and practices in the DevOps and platform engineering space, and choosing the right combination depends on your team’s specific requirements, scale, and operational maturity.
Key Features
Rate
Requests per second shows demand on the service, helping understand traffic patterns and detect anomalies.
Errors
Failed requests per second, either as count or percentage, reveals reliability problems quickly.
Duration
Latency percentiles show how fast the service responds, with p99 capturing worst-case user experience.
Simplicity
Three metrics per service create a manageable monitoring framework that scales across dozens of microservices.
Common Use Cases
Creating standardized Grafana dashboards that show RED metrics for every microservice in the architecture.
Using RED metrics as the basis for SLO definitions that track request success rate and latency targets.
Detecting performance regressions after deployments by comparing RED metrics before and after the release.
Building alerting rules that fire when error rate exceeds a threshold or p99 latency spikes above acceptable levels.
How Obsium Helps
Obsium’s managed observability team helps organizations implement and optimize red method as part of production-grade infrastructure. Whether you are adopting red method for the first time or looking to improve an existing implementation, our engineers bring hands-on experience across cloud platforms and Kubernetes environments. Learn more about our managed observability services →
Frequently Asked Questions
What is RED Method?
RED Method is a monitoring methodology for request-driven microservices that focuses on three key metrics: Rate (requests per second), Errors (failed requests per second), and Duration (distribution of request latency). Created by Tom Wilkie, the RED method simplifies the golden signals into a…
How does RED Method work?
RED Method works by combining the components described in the sections above. The main page walks through the architecture, the typical use cases, and the trade-offs to weigh before adopting it.
Why does RED Method matter?
Teams adopt RED Method to ship faster, run more reliably, and reduce the cognitive load on engineers. The benefits, limits, and adjacent tools are covered in the body above.
When should you use RED Method?
Use RED Method when the problems it solves match what your team is hitting today. The page above outlines the signals that mean you should adopt it now, and the cases where a simpler approach is fine.
