Keep the budget in the SLI's units. A request-based SLO does not imply a fixed number of downtime minutes. Count final logical operations, not each internal retry, and agree on eligibility before measuring the denominator. Source: https://learn.microsoft.com/en-us/azure/well-architected/reliability/metrics

Generic geo-replication is not an unconditional 15-minute RPO guarantee. Geo priority replication has a separate, eligibility-dependent SLA for block blobs: Last Sync Time lag of at most 15 minutes for 99.0% of a billing month. Synchronous replicas do not protect against every failure or accidental deletion. Test restoration and data completeness as well as failover. Sources: https://learn.microsoft.com/en-us/azure/storage/common/storage-redundancy https://learn.microsoft.com/en-us/azure/storage/common/storage-redundancy-priority-replication

Capacity after a zone loss: 70% x 3 / 2 = 105% required capacity, before retries. This is an illustrative equal-capacity, evenly distributed, linear-load model, not a measurement or an Azure guarantee. 105% means demand exceeds capacity, not that measured CPU exceeds 100%. For N equal units losing f units, survivor utilization is baseline x N/(N-f). Three zones at 50% would reach 75% on the two survivors under those assumptions. Actual headroom must cover skew, scaling lag, connection setup, and cache warm-up. This adds a failure-capacity example to the existing scaling discussion. Source: https://learn.microsoft.com/en-us/azure/well-architected/reliability/scaling

Do not default to a timeout below expected p95 latency: that can manufacture failures and extra load. Choose a tolerated false-timeout rate from measured latency, then budget all attempts and waits within the caller's deadline. The June 2026 WAF guide organizes throttling into four boundary types and 14 practices. The patterns themselves, including jitter and bulkheads, are established techniques rather than newly introduced Azure service features. Sources: https://learn.microsoft.com/en-us/azure/well-architected/whats-new https://learn.microsoft.com/en-us/azure/well-architected/design-guides/handle-transient-faults

The new WAF guide identifies these four types. Gateway-only throttling misses internal callers, fan-out, shared pools, and outbound dependencies. Define user limits for fairness and service limits for shared capacity. Match the limiter to what saturates: request rate, concurrency, operation cost, or queue depth. A per-replica limit is not an aggregate dependency budget: 50 calls/s on each of ten replicas can admit 500 calls/s. Keep remote accounting off the critical path where possible, with bounded last-known-good decisions, explicit fallback behavior, and alerts. State-aware policies can protect in-flight transactions, degrade optional features, and shed low-priority work before capacity collapses. Keep integrity and authorization checks intact. Throttling does not replace DDoS protection. The guide's four adoption levels group TP-1–4, TP-5–7, TP-8–11, and TP-12–14. These are separate from the broader five-level Reliability maturity model. Source: https://learn.microsoft.com/en-us/azure/well-architected/design-guides/throttling

Each three includes the initial attempt plus two retries. This is the worst case when nested attempts all exhaust, before any additional fan-out. Choose one retry owner for each dependency interaction. Inspect SDK defaults before adding a resilience library, service-mesh retry, or gateway retry. If multiple layers retry, coordinate an aggregate attempt budget and propagate the same deadline. An outer timeout alone does not cancel downstream work. Source: https://learn.microsoft.com/en-us/azure/well-architected/design-guides/handle-transient-faults

Never retry earlier than the service's minimum delay. Use bounded backoff and jitter when appropriate; do not shorten Retry-After to fit an expiring request. Return an explicit failure or use an agreed durable asynchronous flow instead. The WAF design guide recommends HTTP 429 for caller limits and HTTP 503 for service limits. This is guidance for your API, not a universal Azure convention. Preserve useful downstream backpressure instead of replacing it with generic 500s. Include retry guidance only when retry is safe and intended. Service contracts differ: Cosmos DB can return 429, Blob Storage can return 503 Server Busy or 500 Operation Timeout, and Service Bus uses AMQP exceptions. A timeout after a write does not prove it failed; reconcile before repeating the side effect. Holding threads or unbounded queued retries can worsen overload. Sources: https://learn.microsoft.com/en-us/azure/well-architected/design-guides/throttling https://learn.microsoft.com/en-us/azure/well-architected/design-guides/handle-transient-faults

Ramp percentages are illustrative shares of a measured safe dependency budget, not WAF-prescribed thresholds. Advance only while latency, saturation, errors, and queue age remain acceptable; pause or reopen the circuit on regression. Scope the breaker to the affected dependency so healthy traffic can continue. New work and queued retries must share the same safe concurrency/rate budget. Cache hits are not spare capacity: a 99% to 0% hit-rate drop means 100 times as many origin calls in a simple one-lookup-per-request model, before retries. Recheck deadlines before dispatch. Drop only explicitly discardable, recomputable work; do not discard accepted orders to make a queue look healthy. Source: https://learn.microsoft.com/en-us/azure/well-architected/design-guides/throttling Practices: TP-5, TP-7, TP-8, and TP-12.

An SDK is not a complete business-level resilience policy. You still own the overall deadline, cancellation, idempotency, and aggregate concurrency budget. For example, Blob .NET documents defaults of five retries and 100 seconds per network operation. Neither value is an end-to-end latency guarantee. Service Bus .NET may already have exhausted transient retries before surfacing an exception. Inspect Reason and IsTransient rather than blindly retrying again. Cosmos SDK retries can mask internal 429s: monitor final operation latency and partition-level pressure as well as application exception counts. Sources: https://learn.microsoft.com/en-us/azure/storage/blobs/storage-retry-policy https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-messaging-exceptions-latest https://learn.microsoft.com/en-us/azure/cosmos-db/troubleshoot-request-rate-too-large

The listed alert thresholds/actions are illustrative, not universal WAF rules. Calibrate observation windows and actions to the workload's SLO and risk. Use consistent eligible logical operations for the bad-request fraction. Correlate attempts, delays, and policy versions with final user outcomes: successful retries can mask dependency pressure while increasing tail latency. Source: https://learn.microsoft.com/en-us/azure/well-architected/reliability/monitoring

Use an isolated test environment, representative data, a known-safe rollback, and explicit abort conditions. A stopped instance models capacity loss; it is not a complete simulation of every effect of an availability-zone outage. Do not overload shared Azure resources. Use a controlled stub/proxy or supported fault injection that matches the real dependency's contract and SDK behavior. Calibrate the aggregate 80-call ceiling and timings to the workload. Include initial attempts and SDK retries in the count; verify cancellation and bounds across replicas. Set a measurable recovery target before injecting. Observe final outcomes, p95/p99 latency, retry amplification, current limit utilization, top callers, in-flight work, and oldest queue age during the test. The May 2026 testing refresh emphasizes exhausted built-in mechanisms, scaling lag, and combined tests. TP-11 recommends low-limit exercises with outage drills. Sources: https://learn.microsoft.com/en-us/azure/well-architected/reliability/reliability-test https://learn.microsoft.com/en-us/azure/well-architected/design-guides/testing https://learn.microsoft.com/en-us/azure/well-architected/design-guides/throttling