Glossary · Observability

What Is the RED Method?

RED is the three-number recipe for monitoring any request-driven service: rate, errors, duration.

The RED method monitors three request-centric signals for a service: Rate (requests per second), Errors (failed requests), and Duration (latency distribution). It is a simple, consistent way to monitor request-driven services.

The three signals

Rate is how many requests the service handles per second. Errors is how many of those fail. Duration is how long they take, watched as a distribution so you can see p95 and p99. Applied uniformly across services, RED gives every service the same three dashboards.

When to use RED

RED fits request-driven services, APIs, web services, microservices, well, because it describes them from the caller's perspective. For infrastructure and resources, the USE method is the better lens. Many teams use RED for services and USE for the resources beneath them.

How it fits Ops Singularity

The how-to guides on this site apply RED to services and the how-to dashboards graph exactly these signals, which TelemetryOps then feeds to Sentinel AI.

Frequently asked questions

What does RED stand for?

Rate, Errors, Duration, the three request-centric signals to monitor for a service.

When should I use RED instead of USE?

Use RED for request-driven services and USE for resources; they are complementary lenses, not competitors.

One governed intelligence layer for every operation.

Ops Singularity turns open telemetry into autonomous, governed resolution. See it on your own stack.

Request a Demo → See TelemetryOps