A business app is ready for a failover test or a release when every check below has evidence behind it and a named person has signed. This guide is for IT heads, app owners and engineering managers at mid-size companies in India and the GCC. They run business apps on AWS, Azure or both. It gives a high availability checklist of 27 checks in seven parts. Each check names where to look on AWS and on Azure. It also gives the evidence to collect, a suggested owner and the risk if it is skipped. Use it to review one app at a time, and treat a check without evidence as not done.
Last reviewed 2026-11-01 by Manish Sharma.
High Availability Checklist for Business Applications: The Short Answer
Work through seven parts in order. They are targets and ownership, architecture and redundancy, data and recovery, failover and dependencies, capacity, change and release safety, then monitoring, testing and runbooks. Record what you find, then name the owner and decide at a gate whether to go ahead. A high availability checklist here is a review of one app, not a design. Treated as a structured application availability assessment, the review replaces opinions with evidence.
How to Use the 27 Checks
Set aside a session with the app owner and an engineer who knows the platform well. Then, for each row, write down what you saw, the evidence (an export, a screenshot, a test result) and the person who confirmed it. A check passes only with its evidence. Change nothing yet, because this pass is about learning where the app stands.
The owner and risk columns are suggestions to adapt, not facts about your team. So replace them with the people and risks that apply to your app.
A check with no evidence counts as open. The gate at the end reads the evidence, so keep it where the approver can find it.
High Availability Checklist, Part 1: Targets and Ownership
Four checks fix what the app must deliver and who is responsible, because without them nobody can say later whether a failure was acceptable.
| Check | Where to look on AWS | Where to look on Azure | Evidence | Suggested owner | Risk if skipped |
|---|---|---|---|---|---|
| 1. An availability target for each critical user journey | Written target; Amazon CloudWatch for current figures | Written target; Azure Monitor for current figures | Target per journey, signed by the business owner | Business owner | Effort goes to the wrong journey |
| 2. Recovery time (RTO) and recovery point (RPO) objectives agreed and written | Recovery documents; AWS Backup settings | Recovery documents; Azure Backup settings | RTO and RPO per workload, in writing | Application owner | Recovery has no goal to test against |
| 3. A named owner and an escalation path | On-call schedule; account contacts | On-call schedule; subscription contacts | Names and a tested contact route | Engineering lead | No one acts on a failure |
| 4. Maintenance windows and acceptable degraded modes | Change calendar | Change calendar | Agreed windows and a list of acceptable reduced service | Application owner | Planned work counted as an outage, or the reverse |
RTO is how long recovery may take. RPO is how much data you can afford to lose, measured in time.
A target is arithmetic on time. For example, in a 30-day month, 99.9% allows about 43 minutes of downtime and 99.99% about 4.3 minutes. For a 365-day year, 99.999% allows about 5.3 minutes.
High Availability Checklist, Part 2: Architecture and Redundancy
Four checks look for the single points of failure, meaning parts whose failure stops the whole app. Review them with an architect, because they know the design.
| Check | Where to look on AWS | Where to look on Azure | Evidence | Suggested owner | Risk if skipped |
|---|---|---|---|---|---|
| 5. A failure-mode analysis across compute, storage, network, DNS, identity, third-party APIs and configuration | Architecture diagram and review notes | Architecture diagram and review notes | A written list of what can fail and what happens | Architect | A part nobody thought of fails first |
| 6. No single point of failure left in the critical path | Resource list for the path | Resource list for the path | A diagram marking each part and its backup | Architect | One part takes the journey down |
| 7. Deployed across more than one availability zone where the region supports it | Availability Zone settings | Availability zone settings | Zone map of each tier | Platform team | A zone failure stops the app |
| 8. Load balancers with health checks that test real function | Elastic Load Balancing health checks | Azure Load Balancer or Application Gateway health probes | Health check configuration and a result | Platform team | A broken server keeps receiving traffic |
A health check tells a load balancer whether a server can serve requests.
Still, zones do not protect against the loss of a whole region. Microsoft states this for Azure availability zones. Decide separately whether the app needs a second region.
High Availability Checklist, Part 3: Data and Recovery
Four checks cover whether the data can be recovered. Replication protects against failure, but AWS notes that continuous replication may not protect against data corruption or deletion, which can reach every copy.
| Check | Where to look on AWS | Where to look on Azure | Evidence | Suggested owner | Risk if skipped |
|---|---|---|---|---|---|
| 9. Automated, encrypted backups kept in a separate location or account | AWS Backup plans and vaults | Azure Backup policies and vaults | Backup list with location and encryption status | Backup owner | One incident reaches the data and its backups |
| 10. A restore tested in isolation | AWS Backup restore testing | Azure Backup restore test | A recorded restore: backup ID, time taken, checks run, who, when | Backup owner | Backups exist but do not restore |
| 11. Replication lag monitored against the RPO | Replication metrics in CloudWatch | Replication metrics in Azure Monitor | Lag graph against the RPO | Database owner | Data in the lag window is lost on failover |
| 12. A current runbook for failover and failback, with configuration kept outside the primary location | Runbook repository | Runbook repository | Runbook with a last-reviewed date | Engineering lead | The team improvises during an outage |
Replication lag is the delay before a change on the primary shows up on the copy. For Azure SQL Managed Instance, Microsoft’s checklist says that replication to the secondary region is asynchronous. It also says transactions committed within the replication lag are lost on a geo-failover. That is guidance for one product, so check how your own database behaves. Failback is the return to the primary after a failover.
High Availability Checklist, Part 4: Failover and Dependencies
Four checks cover what the app does when something it depends on fails.
| Check | Where to look on AWS | Where to look on Azure | Evidence | Suggested owner | Risk if skipped |
|---|---|---|---|---|---|
| 13. Failover automated where safe, and manual steps written where approval is needed | Failover configuration; runbook | Failover configuration; runbook | Which steps are automatic, which manual, and who approves | Engineering lead | Failover waits on someone who cannot be reached |
| 14. Timeouts, bounded retries with exponential backoff and jitter, and circuit breakers | Application code and configuration | Application code and configuration | Settings reviewed against each dependency | Application owner | Retries add load to a struggling system |
| 15. External dependencies mapped, with a degraded mode for each | Dependency list | Dependency list | A table of dependencies and what happens when each fails | Application owner | A payment or login provider fails with no fallback |
| 16. DNS, connection-string, firewall, IAM and routing changes after a regional failover defined | Route 53, security group and IAM settings | Azure DNS, network rules and role assignments | A list of every change needed after failover, with an owner | Platform team | The secondary is up but unreachable |
Retries are safe only for idempotent operations, where doing the same thing twice has the same effect as doing it once. For example, a payment retry that charges twice.
Our post on cloud outage resilience covers outages at the provider level.
Key Takeaway Redundancy only helps if failover works and the app can reach the copy, so check both.
High Availability Checklist, Part 5: Capacity
Three checks look at what runs out first. The AWS Well-Architected Framework advises that you stop guessing capacity and monitor demand and utilization.
| Check | Where to look on AWS | Where to look on Azure | Evidence | Suggested owner | Risk if skipped |
|---|---|---|---|---|---|
| 17. Saturation of the most constrained resource monitored against a utilization target | CloudWatch resource metrics | Azure Monitor resource metrics | Graph of the tightest resource against its target | Platform team | The app fails before the alert |
| 18. Scaling, quotas and load shedding configured | Auto Scaling settings; service quotas | Autoscale settings; subscription quotas | Scaling rules and quota headroom | Platform team | A spike meets a quota or a slow scale-up |
| 19. A load test before the next peak | Test results | Test results | Test report at the expected peak | Application owner | The peak is the first real test |
High Availability Checklist, Part 6: Change and Release Safety
Four checks look at how changes reach production. The AWS whitepaper “Availability and Beyond” cites a 1985 study by Jim Gray. It says failure is driven primarily by software and operations.
| Check | Where to look on AWS | Where to look on Azure | Evidence | Suggested owner | Risk if skipped |
|---|---|---|---|---|---|
| 20. Small, automated deployments | Pipeline definition | Pipeline definition | Pipeline run history | Engineering lead | Large manual releases fail in large ways |
| 21. A tested rollback path | Rollback runbook and a test | Rollback runbook and a test | A recorded rollback test | Engineering lead | A bad release stays live |
| 22. Progressive rollout | Deployment configuration | Deployment configuration | Rollout stages and the checks between them | Engineering lead | A fault reaches every user at once |
| 23. Who can change production, with changes tracked and least-privilege access | IAM policies; change log | Role assignments; change log | Access list and a change log with times | Security lead | Untracked changes cannot be linked to failures |
Manual changes are the hardest to review and undo. So record who made each one, when, and how to reverse it.
High Availability Checklist, Part 7: Monitoring, Testing and Runbooks
Four checks confirm that you will know about a failure, and that you have practiced the response before users find out.
| Check | Where to look on AWS | Where to look on Azure | Evidence | Suggested owner | Risk if skipped |
|---|---|---|---|---|---|
| 24. The four signals (latency, traffic, errors, saturation) alerting on symptoms users feel | CloudWatch alarms | Azure Monitor alerts | Alert list with thresholds and recipients | Operations owner | Users report the failure first |
| 25. External synthetic checks, including certificate expiry | Route 53 health checks or an external probe | Application Insights availability tests | Check results from several locations | Operations owner | A silent failure goes unseen |
| 26. A failover or recovery drill held, with the result recorded | AWS Fault Injection Service for fault tests | Azure Chaos Studio for fault tests (Workspaces and Scenarios are in preview, as of November 2026) | Drill report with measured recovery time | Engineering lead | Recovery has never been run |
| 27. An on-call response written and current | Runbook and rota | Runbook and rota | Runbook with a last-reviewed date | Operations owner | The response depends on one person |
The four signals come from Google’s Site Reliability Engineering book. Microsoft’s Standard availability tests in Application Insights check availability, response time and TLS/SSL certificate validity from several locations. With retries enabled, which Microsoft recommends, a test reports a failure only if three successive attempts fail. Uptime monitoring that runs only inside the app stops when the app stops, so keep at least one check outside it.
Key Takeaway A drill with a recorded result is the difference between a plan and an assumption.
The Go/No-Go Gate
Go ahead with a failover test or a release only with evidence for every part. You also need a named approver. So a verbal yes is not approval.
What the Gate Needs
Gather it for every part, from targets to monitoring.
Choose one accountable person, not a committee.
Fix the point at which you stop and go back.
Note the date and the evidence it rested on.
What a Finding Record Holds
For each check, keep the check, the owner, the evidence, the decision and the date. Then add a risk register entry for anything unresolved, with the mitigation and the owner.
A gap with an owner and a date is manageable, but a gap everyone knows about and nobody owns is how an outage repeats.
What This Checklist Does Not Cover
This high availability checklist reviews one app. It does not give the method for fixing what it finds, explain the causes of downtime in detail or compare high availability with disaster recovery. It is not a migration checklist either. For that, see our cloud migration checklist. No template file is provided, so use the evidence and finding record described above as your structure.
For the wider picture, see how Signisys helps with application uptime and availability. Our page on cloud architecture, reliability and resilience adds detail. See also cloud services and platform engineering.
References
- Microsoft Learn, High availability and disaster recovery checklist for Azure SQL Managed Instance, Azure SQL.
- Microsoft Learn, What are Azure Availability Zones?, Azure Reliability.
- AWS Well-Architected Framework, Design principles, Reliability pillar.
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.