# Reliability (/docs/strategies/reliability)



Reliability strategies keep traffic away from **failing** recipients. They read a
rich set of reliability facts — circuit state, error rate, latency p95, retry-after
backoff, error-budget burn, saturation, brownout, staleness — and use them to
penalize or exclude targets that are degrading, so failures drain instead of
cascade.

Two layers are involved: the reliability readiness plane projects operational
health, and the `reliability_weighted` built-in strategy consumes those facts.
The strategy reads only the `reliability.*` feature keys on
`SelectRequest.Features`.

| Strategy                                        | Output        | Status    |
| ----------------------------------------------- | ------------- | --------- |
| [Reliability readiness](#reliability-readiness) | policy        | Available |
| [Reliability-weighted](#reliability-weighted)   | single-winner | Built in  |

<Callout title="Reliability facts" type="info">
  The readiness signal is computed from circuit state, error-rate EWMA, consecutive
  failures, latency p95, timeout rate, retry-after-until, retry-budget remaining,
  error-budget burn, saturation ratio, brownout flag, and freshness — all available
  as typed feature keys, so any scorer can consult them.
</Callout>

## Reliability readiness [#reliability-readiness]

**Output:** policy

The **readiness projection**: a routing-safe signal plane that composes circuit
breakers, webhooks, adaptive flow control, credential health, availability, quota,
usage budgets, and entitlement policy into one queryable set of states —
**ready, degraded, brownout, blocked, probing, unknown, stale** — scoped by tenant,
environment, and target.

**Why it matters.** Every subsystem has its own health signal; without a common
model each strategy would re-derive "is this target OK?" differently. Readiness
collapses those signals into one answer, with provenance, so a blocked route can
explain *why* — circuit-open recipient, stale availability, quota backoff, budget
pressure, entitlement denial, or brownout.

**Distinguish the two layers.** The readiness projection is the deeper plane: it
ingests observations, upserts current facts, and exposes API/MCP operations
(`reliability_readiness_get`, `reliability_decision_explain`, and more). A routing
strategy never touches that plane directly — it reads the bounded `reliability.*`
numeric keys the projection lands in the [feature snapshot](/docs/strategies/contracts#strategy-feature-snapshot).
Stale facts can't project as `ready`; unknown facts fail closed unless policy
allows fail-open.

**Where it fits.** The input other strategies read — chiefly
[reliability-weighted](#reliability-weighted) below.

## Reliability-weighted [#reliability-weighted]

**Output:** single-winner · Built in

A **recipe**: take any base score and apply **readiness penalties** — blocked
targets are excluded, degraded and brownout targets are penalized — so traffic
drains away from failing recipients before they cascade.

**Why use it.** It layers failure-awareness onto whatever selection you already
use. Your base strategy proposes a distribution; reliability-weighting removes the
targets that shouldn't get traffic and dampens the ones that are struggling,
without you hand-coding circuit logic into each strategy.

**How it works.** It wraps a base strategy (default
`smooth_weighted_round_robin`) and adjusts scores using the readiness facts:
`blocked` → out, `degraded`/`brownout` → penalized. It consumes the
[readiness projection](#reliability-readiness) through the `reliability.*` feature
keys. It records the reliability keys it considered in the explain feature trace.

**Where it fits.** The `Select` stage, as a reliability-aware wrapper over a base
distribution strategy.

## Related [#related]

<Cards>
  <Card title="Failover" href="/docs/strategies/balance#failover">
    Active-passive routing for primary and backup recipients.
  </Card>

  <Card title="Feature snapshot" href="/docs/strategies/contracts#strategy-feature-snapshot">
    The typed reliability facts these strategies consume.
  </Card>
</Cards>