Skip to content

Silurian Docs

All documentation Security and performance

Traffic services

An overview of Cloudflare's traffic-shaping tools - smart routing, tiered caching, load balancing, health checks and waiting rooms - and when each one is useful.

Public guideReviewed 2026-09-11

Traffic product architecture

Argo, Tiered Cache, Load Balancing, Health Checks and Waiting Rooms solve different latency, origin-load, availability and admission problems.

Choose the product that matches the bottleneck

Argo Smart Routing optimizes the network path between Cloudflare and the origin. Tiered Cache reduces repeated cache misses reaching the origin. Load Balancing selects among pools and endpoints. Health Checks measure endpoint availability. Waiting Rooms control admission to a busy application. These products complement one another but solve different failure modes.

Argo Smart Routing

Argo uses real-time network intelligence to select an efficient path for eligible origin traffic. Its analytics compare origin time to first byte for requests using a Smart Route with ordinary paths. Detailed origin-performance data requires enough recent origin requests to produce a meaningful comparison.

  • Use Argo for path latency and reliability, not slow application code.
  • Compare representative regions and error rate as well as median latency.
  • Argo is usage-based; confirm expected traffic before activation.

Tiered Cache

Without tiering, several Cloudflare locations can independently miss and contact the origin. Tiered Cache lets lower tiers ask selected upper tiers first, so fewer locations make origin requests. This raises cache reuse and reduces origin connections and bandwidth.

  • Smart Tiered Cache selects an upper tier from Cloudflare topology.
  • Uncacheable, bypassed and expired responses can still reach the origin.
  • With Load Balancing, upper-tier selection relates to the pool and can affect origin distribution.

Routing and cache topology

Network path selection, cache tiers, pools and endpoints determine where a request travels and which origin receives it.

Load Balancing components

A load balancer publishes the traffic entry point. Pools organize endpoints, endpoints are the actual destinations, and monitors define health probes. A fallback pool receives traffic when no ordinary healthy pool is available. Model these components before selecting a steering policy.

Health monitors and endpoint status

A monitor sends periodic HTTP, HTTPS or TCP probes and evaluates reachability, timeout, expected status and optionally response content. Cloudflare samples from several data centers in each selected region; regional and endpoint health are derived from those results.

  • Use a path that proves the application dependency is usable, not only that a web server answers.
  • Set consecutive up and down thresholds to damp transient failures.
  • Low intervals across many regions can create substantial origin traffic.

Availability and admission control

Health probes, steering policy and queue limits should represent real application capacity rather than a shallow connectivity check.

Steering and failover

Failover steering tries pools in order and returns to the primary when it becomes healthy again. Random steering distributes among healthy pools and can use weights. Dynamic steering uses monitor round-trip time profiles; if no current profile exists, Cloudflare falls back to configured pool order. The fallback pool remains the destination of last resort.

  • Every failover pool must have capacity for the traffic it can receive.
  • Session affinity can delay failback for existing clients.
  • Test the real failure mode, not only a manual pool disable.

Waiting Rooms

A Waiting Room limits concurrent active users and admission rate for selected application paths. Queued visitors receive a managed page and a session cookie controls their progress and re-entry. Set total active users and new users per minute from measured application capacity.

  • Protect the bottleneck path, not necessarily every static asset.
  • Test queueing, session duration, mobile behaviour and accessibility before an event.
  • A Waiting Room controls admission; it does not add origin capacity.

Capacity, usage and recovery

Commercial units and operational metrics must be measured before activation and throughout a controlled failover or rollback.

Commercial usage and capacity

Argo, Load Balancing, Health Checks and Waiting Rooms can be paid add-ons or usage-based services. Estimate requests, endpoints, monitor frequency and event traffic. Silurian billing is the commercial record; Cloudflare analytics remains operational evidence for understanding consumption.

Observe and recover from a traffic change

Measure origin request count, cache-hit ratio, latency, error rate, endpoint health and pool selection before and after activation. To recover, restore the prior routing, tiering or admission state and confirm traffic returns to the expected origin. Keep monitors running long enough to separate a transient network fault from a persistent application failure.