Methodology
Resiliency tiers
Each tier defines a single RPO/RTO threshold, in minutes. A service scope only meets a tier if both its RPO and RTO figures fit under that threshold.
| Tier | RPO / RTO | Profile |
|---|---|---|
| Tier 0 | 15 minutes | Mission-critical. Loss of service or data beyond 15 minutes is unacceptable. |
| Tier 1 | 1 hour | Business-critical. Significant business impact if unavailable for more than an hour. |
| Tier 2 | 6 hours | Important. Moderate business impact tolerated for up to 6 hours. |
| Tier 3 | 24 hours | Standard. Limited business impact tolerated for up to a day. |
| Tier 4 | 1 week | Low priority. Extended outage or data loss window is acceptable. |
How Pass / Risk / Fail is decided
For each redundancy option (Local, Zonal, or Regional), the tool compares the option's stated RPO and RTO — in minutes — against the selected tier's threshold, then checks how the option actually fails over.
Both RPO and RTO fit within the tier threshold, and failover is automatic with an SLA-backed or explicitly committed RPO. This is the only status that represents a platform guarantee rather than an operational dependency.
The numbers technically fit the tier, but something about how you get there isn't guaranteed — failover requires a human or a runbook to trigger it, or the RPO is "typical" rather than contractual. The tier threshold assumes the clock starts immediately; a manual trigger means it doesn't start until someone notices and acts, which most vendor RTO figures don't include.
The option's RPO or RTO numerically exceeds the tier threshold, even in the best case.
There is no fixed RPO/RTO for this option — it depends entirely on an architecture you'd have to design and build (e.g. a custom multi-region pattern). Treat this as "needs a design decision," not as a pass.
Keeping this current
Azure changes redundancy features, SLAs, and retirement timelines regularly — several entries in this catalog reflect changes from the past year (Storage's Geo-priority replication RPO guarantee, Service Bus's data-replicating Geo-Replication feature, Cosmos DB's Per-Partition Automatic Failover, and the Azure Cache for Redis retirement, among others).
Each service entry has a lastVerified date and a list of source URLs. Data lives as plain TypeScript objects in src/lib/services/*.ts — one file per service — so updating a figure is a normal code change: check the linked Microsoft Learn page, edit the relevant field, bump lastVerified, and commit.
This is a reference and starting point for a resiliency review, not a substitute for the current Azure SLA documents or Microsoft Learn.