Step 1 — Identify at-risk origins
Using your internal metrics, identify origins at risk of reaching their failure threshold.
- If your origin is seeing increased traffic but is not yet at risk of failure, start with .
- If your origin is about to fail, start with .
Step 2 — Shed default traffic from a pool
Configure via dashboard
To enable load shedding for a specific pool via the dashboard:
Go to Traffic > Load Balancing.
Click Manage Pools.
On a pool, click Edit.
Click the Configure Load Shedding dropdown.
For Default traffic, select a Policy and a Shed %:
Policy optionsWhen shedding Default traffic, you have two Policy options:
- Random: Randomly sheds the percentage of requests specified in the Shed %. Distributes traffic more accurately, but may cause requests from the same IP to hit different origins.
- IP hash: Sheds the percentage of IP address hash space specified in the Shed %. Ensures requests from the same IP will hit the same origin, but may shed a significantly higher or lower percentage of requests.
Configure via API
To enable load shedding for a specific pool via the API, for the pool’s
Step 3 — Monitor traffic
Once you have started shedding default traffic, evaluate the effects by reviewing the in Load Balancing analytics. Based on these numbers and your internal metrics, you will know whether you need to divert additional traffic from the pool.
If you see increased traffic to a pool, you may need to shed additional traffic. Pools shed a percentage of total traffic, so any increase in total traffic will also increase the traffic reaching your pool.
Step 4 — Shed additional traffic (optional)
If you need to shed additional pool traffic:
- Follow the steps outlined in .
- In the dashboard, increase the Shed % for Default traffic and/or Session affinity traffic.
- For the API, increase the value for
Since shedding Session Affinity traffic will disrupt and may degrade the customer experience, only enable this option if your pool is in imminent danger of becoming unhealthy or your pool has a high percentage of traffic related to existing sessions. For more guidance, see .
Step 5 — Disable load shedding
Once an origin is no longer at risk, remove load shedding from the pool.
For Default traffic, you have two choices for shedding policy.
A Random policy:
- Randomly sheds the percentage of requests specified in the Shed %.
- Distributes traffic more accurately because it sheds at the request level.
- May cause requests from the same IP to hit different origins, potentially leading to cache misses, inconsistent latency, or session disruption for .
An IP hash policy:
- Sheds the percentage of IP address hash space specified in the Shed %.
- Ensures requests from the same IP will hit the same origin, which will increase cache hits, provide consistent latency, and preserve sessions.
- Can over- or under-shed requests, since hashing does not guarantee a perfectly even IP distribution and individual IPs may be responsible for different percentages of your requests.
Choose a Random policy when you want a more accurate distribution of raw requests and an IP hash policy when you want to prevent a single IP from flapping between different origins.
If all pools within a load balancer have Load shedding enabled, some traffic will go to the fallback pool. To prevent any traffic from reaching the fallback pool, ensure at least one pool within the load balancer does not have load shedding enabled.
Pools in multiple load balancers
If you enable load shedding on an origin pool, it will shed the same percentage of traffic across all your load balancers. If you need an origin to shed different percentages of traffic for different load balancers, put that origin in multiple pools.