Application downtime comes from a short list of causes, and each cause shows a sign first, in latency, errors or saturation, ahead of the user complaints. This guide is for IT heads, application owners and engineering managers at mid-size companies in India and the GCC. They run business applications on AWS, Azure or both. It names five common causes and four signals that give early warning. It then shows where to check each one on AWS and on Azure. The aim is for the warning to reach you first.
Last reviewed 2026-11-01 by Manish Sharma.
Application Downtime: The Short Answer
The five causes are running out of capacity, changes that go wrong, dependencies that fail, infrastructure failures and attacks that exhaust capacity. The four signals to watch are latency, traffic, errors and saturation. Match each cause to its first sign. Give every application an owner for the warning. Check from outside the application as well as inside it.
Key Takeaway Each cause leaves a trail, so watch the trail and name an owner for it before the outage.
What Counts as Application Downtime
Application downtime is a period when an application, or a key feature of it, is not available or does not work as intended. Partial failures count. If login works but payment fails, the application is down for the customer who is paying. Planned maintenance is downtime too. Count it apart from unplanned outages, because the response and the target differ.
Availability Targets in Minutes
An availability target is a share of time. Turn it into minutes, and the business can discuss it more easily. This is arithmetic, not a measured result, and it assumes a 30-day month and a 365-day year.
| Target | Allowed downtime per 30-day month | Allowed downtime per 365-day year |
|---|---|---|
| 99.9% | 43.2 minutes | 8.76 hours |
| 99.99% | 4.32 minutes | 52.6 minutes |
| 99.999% | 26 seconds | 5.26 minutes |
System uptime is the time the system runs. Application availability is the share of time users can use it. Track the time to recover and how often incidents happen as well, because a target that ignores them hides a pattern of short outages.
Application Downtime, Cause 1: Running Out of Capacity
Application downtime starts when demand passes what the tightest component can handle. That component can be a database, an API limit or an integration instead of the web servers.
The first sign is latency on the slowest requests, followed by saturation. Saturation is how full the tightest resource is. Google’s Site Reliability Engineering book notes that many systems degrade before they reach 100% utilization. Set a target below the limit. Treat predicted saturation as a warning too. Related signals include database latency, API errors, memory pressure and full caches.
For each application, find the one resource that fills first, and alert on it before it is full.
Application Downtime, Cause 2: Changes That Go Wrong
A change can trigger application downtime, whether it is a release, a configuration edit or a deletion. Causes include a fragile release, a failed deployment, a misconfiguration, accidental deletion and human error.
The first sign is the error rate stepping up soon after a change. Record when changes happen, so the error graph and the change log can sit side by side. Test deployments, staged rollouts and a rehearsed rollback reduce the risk. The method is in our guide on how to improve application availability.
A change with no recorded time and no named owner is hard to link to the errors that follow it.
Application Downtime, Cause 3: Dependencies That Fail
Your application is only as available as what it calls, so a failing dependency adds downtime. Third-party services such as payment gateways and authentication providers can fail, and so can DNS and certificates.
The first sign is a dependency’s latency or error rate moving, or a certificate nearing expiry. AWS Well-Architected describes recording latency, error rates and availability for each request, for all dependencies and for key operations. A failing dependency then shows up as its own line and not as a vague slowdown. On Azure, Application Insights Standard availability tests can check TLS/SSL certificate validity. They also include a lifetime check, where you set a period before the certificate expires.
Application Downtime, Cause 4: Infrastructure Failures
Hardware, power, network or a cloud service disruption can cause application downtime in an otherwise healthy app.
The first signs are failed health checks, or failures that retries are hiding. A request that succeeds on the second try looks fine in a success rate and still costs the user time. For failures at the provider level, our post on cloud outage resilience covers how to plan for them.
Track retries as their own signal, next to the success rate.
Application Downtime, Cause 5: Attacks That Exhaust Capacity
Traffic that uses up capacity looks like cause 1 to the application. Whether the demand is a surge of customers or a deliberate attack, the signs are the same. Latency rises, then saturation, then errors.
This guide covers only what shows in the application’s own signals. It does not describe security operations, and it makes no claim to detect or respond to an attack for you.
Application Downtime: The Early Warning Signs to Watch
Four signals give a baseline for an application, and they come from the Google SRE book: latency, traffic, errors and saturation.
Latency, Traffic, Errors and Saturation
| Signal | What it measures | What a warning looks like | Example check on AWS | Example check on Azure |
|---|---|---|---|---|
| Latency | Time to serve a request | The slowest requests get slower | Load balancer and application metrics in Amazon CloudWatch | Response-time metrics in Azure Monitor and Application Insights |
| Traffic | Demand on the system | A sudden jump or drop | Request counts in CloudWatch | Request counts in Application Insights |
| Errors | Rate of failing requests | The error rate steps up | Error counts and alarms in CloudWatch | Failed requests in Application Insights |
| Saturation | How full the tightest resource is | Utilization climbs toward the limit | Resource utilization metrics in CloudWatch | Resource metrics in Azure Monitor |
Track the latency of successful and failed requests apart, because failed requests can distort an average. The SRE book notes that a slow error is even worse than a fast one. It also describes three kinds of error. An explicit error is a failure code. An implicit error is a successful response with the wrong content. A policy error is a response slower than an agreed limit. Report names change, so confirm the current ones in the console.
Watch the Tail, Not the Average
Look at a high percentile over a short window, as well as the average. The SRE book says latency increases can be a leading indicator of saturation. AWS focuses on latency outliers, the 99.9th and 99.99th percentiles, and gives its reason: if one request out of 1,000 or 10,000 is slow, that is still a poor experience.
A slow request that is one in 1,000 barely shows in an average, but the person who sent it still had a poor experience. That is AWS’s reason for watching the tail.
Silent Failures and Symptoms First
The worst failure is the silent one. AWS Well-Architected describes the silent failure as the worst failure mode, and says customers know before you do. A job that stops with no error can leave every dashboard green. So can a page that loads but returns nothing.
Three habits help. Alert on symptoms that users feel, and on internal causes too. Keep alerting apart from the systems it watches, so a failure cannot silence its own alarm. Run synthetic checks from several locations. These are scripted requests that test an application from outside.
With retries enabled, which Microsoft recommends, an Application Insights availability test reports a failure only if three successive attempts fail. Microsoft says that on average about 80% of failures disappear on retry, which is a statement about its own tests. Microsoft recommends at least five test locations. Use Standard tests, because Microsoft has deprecated URL ping tests and plans to remove them on 30 September 2028 (as of November 2026). Page a person only for problems that are urgent and actionable.
A check that runs on the same host as the application stops when the host stops. Run at least one check from outside.
A Map From Application Downtime Cause to First Sign
Use this map as a starting point for each application.
| Cause | First sign | What to check | Where to look on AWS | Where to look on Azure |
|---|---|---|---|---|
| Capacity | Slowest-request latency rises, then saturation | Database, API and integration limits | CloudWatch resource metrics | Azure Monitor resource metrics |
| Changes | Errors step up after a change | The change log against the error graph | CloudWatch alarms with a change record | Application Insights failures with a change record |
| Dependencies | A dependency slows or errors; a certificate nears expiry | Per-dependency latency and errors | CloudWatch metrics per dependency | Application Insights dependency data; availability test certificate check |
| Infrastructure | Failed health checks; hidden retries | Health checks and retry counts | Load balancer health checks | Availability tests from several locations |
| Attacks that exhaust capacity | Latency, then saturation, then errors | Traffic against normal demand | CloudWatch traffic and saturation | Azure Monitor traffic and saturation |
Key Takeaway The same four signals cover all five causes, so a small set of well-chosen alerts goes a long way.
What to Do With a Warning Sign
Decide who owns the warning before it fires. A sign with no owner is just a graph.
Check the signal from a second place, since a single reading can mislead.
Name the person or team that can change the thing the signal points at.
Act if users are affected or the trend is clear, and watch if not.
Note the sign, the decision and the result, so the pattern shows up over time.
The fixes are in a separate guide. This one stops at the warning.
What This Article Does Not Cover, and When to Get Help
This article explains causes and signs. It does not give the fixes, a high availability checklist or the difference between high availability and disaster recovery, and it does not cover provider outages beyond the pointer above. For the wider picture, see how Signisys helps you improve application uptime and availability. Our page on cloud architecture, reliability and resilience adds detail.
An outside review helps when no one owns an application’s availability, when outages keep happening with no pattern, or when nothing checks the application from outside itself. See also cloud services and platform engineering.
References
- Google, Monitoring Distributed Systems, Site Reliability Engineering book.
- AWS Well-Architected Framework, Monitor workload resources, Reliability pillar.
- Microsoft Learn, Application Insights availability tests, Azure Monitor.
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.