Cloud SLA monitoring tools: what to use and how to choose
Country Manager, Sweden
AI, DevOps, Security, and Cloud Solutioning. 12+ years leading enterprise cloud transformation across Scandinavia
Cloud SLA monitoring tools measure availability, latency and error rates from your users' side and compare them with the targets in your provider and customer SLAs. Most teams combine three layers: the cloud's native monitoring (CloudWatch, Azure Monitor, Google Cloud Monitoring), an observability platform such as Datadog or Dynatrace, and external synthetic checks.
Key takeaways
- Provider SLAs pay service credits, not damages, and you usually have to claim them with your own evidence. AWS, for example, requires an EC2 claim by the end of the second billing cycle after the incident.
- Monitor what users experience (synthetic checks and real request data), not only whether a VM is running.
- Define service level indicators (SLIs) and objectives (SLOs) first, then pick tools that can calculate them, alert on error-budget burn and produce monthly reports.
- Native tools cover one cloud well and cost little to start. Third-party platforms add multi-cloud views, APM and SLO reporting across everything.
- Keep at least one check outside your main cloud provider, so an outage cannot take down the monitoring along with the service.
What is cloud SLA monitoring?
It is the continuous measurement of a service against the commitments in a service level agreement. There are two directions, and you usually need both:
- Provider SLAs: what AWS, Azure, Google Cloud or a SaaS vendor promises you. The Amazon EC2 SLA, for example, sets 99.99% monthly uptime per Region for instances deployed across two or more Availability Zones, and 99.5% for a single instance.
- Your own SLAs: what you promise your customers or internal business owners, such as 99.9% availability for an order portal during business hours.
The provider SLA only covers its own service. Your application's availability depends on every component in the chain, so you need your own measurements to know whether you met your promise.
What do the uptime percentages mean in minutes?
| Monthly availability target | Allowed downtime in a 30-day month |
|---|---|
| 99.5% | 3 hours 36 minutes |
| 99.9% | 43 minutes 12 seconds |
| 99.95% | 21 minutes 36 seconds |
| 99.99% | 4 minutes 19 seconds |
Every extra "nine" cuts the allowed downtime by a factor of ten, which is why tight targets need fast detection. A check that runs every five minutes cannot prove a 99.99% month.
Why do you need your own monitoring?
Because the provider will not tell you when it owes you money, and its dashboard does not show your users' experience.
Provider SLAs share a few traits. They define availability narrowly and pay credits as a percentage of the monthly fee for the affected service. They also exclude many causes. You must file the claim yourself, with logs that show the impact, within a deadline. Our guide to calculating and claiming cloud SLA credits walks through the rules for AWS, Azure and Google Cloud.
More important than credits: an SLA breach toward your own customers is your problem, whatever caused it. Monitoring tells you about degradation before customers do, and gives you the data for root-cause analysis and service reviews.
SLIs, SLOs and error budgets
Good SLA monitoring starts with three definitions, popularised by Google's Site Reliability Engineering book:
- Service level indicator (SLI): a measured value, such as the share of HTTP requests that succeed in under 300 ms.
- Service level objective (SLO): the internal target for the SLI, such as 99.9% over 30 days. Set it a little stricter than the external SLA so you get a warning before the contract is breached.
- Error budget: the failure an SLO allows (0.1% of requests for 99.9%). When the budget burns fast, teams slow down releases and fix reliability first.
The major clouds now support this model natively. Amazon CloudWatch has service level objectives with error budget and burn-rate alarms. Google Cloud Monitoring has SLO monitoring built in. For help setting realistic numbers, see how to define cloud SLA targets.
What should a cloud SLA monitoring tool do?
Use this checklist when you compare tools:
- Synthetic checks: scripted HTTP, API and browser tests from several locations, at intervals short enough for your target.
- Real user and request data: success rates and latency from load balancer logs, APM traces or real user monitoring.
- SLO calculation: SLIs and SLOs over rolling and calendar windows, with error budgets and burn-rate alerts.
- Alert routing: integration with on-call tools, chat and your ITSM system, with severity and escalation rules.
- Provider health signals: ingestion of AWS Health, Azure Service Health or Google Cloud status events, so you can separate provider incidents from your own.
- Reporting: monthly availability reports per service and customer, exportable as evidence for credit claims and service reviews.
- Multi-cloud and hybrid coverage: one view across clouds, SaaS and on-premises if you run more than one platform.
- Data residency and access control: where monitoring data is stored, and role-based access, which matters under GDPR and NIS2.
Cloud SLA monitoring tools by category
These are well-known options grouped by type, not a ranking. Capabilities change often, so check each vendor's current documentation and pricing.
| Category | Examples | Strengths | Trade-offs |
|---|---|---|---|
| Native cloud monitoring | Amazon CloudWatch (with Synthetics and Application Signals), Azure Monitor and Application Insights, Google Cloud Monitoring | Deep integration, no extra vendor, pay-as-you-go, built-in SLOs on AWS and Google Cloud | One cloud per tool, and limited cross-cloud reporting |
| Observability platforms | Datadog, Dynatrace, New Relic, Splunk Observability Cloud, Grafana Cloud | Multi-cloud views, APM, synthetics and SLO dashboards in one place | Cost grows with hosts, data volume and features, so budget carefully |
| Open source | Prometheus with Grafana, Zabbix, Uptime Kuma | No licence cost, full control, and data stays where you host it | You run, scale and secure it yourself |
| External uptime and synthetic services | Pingdom, Checkly, Site24x7, UptimeRobot | Independent vantage points outside your cloud, quick to set up | Mostly outside-in checks, not internal metrics |
| Incident, status and ITSM tools | PagerDuty, Atlassian Statuspage, ServiceNow, Jira Service Management | On-call routing, customer status pages, SLA timers for tickets | Need monitoring data fed in from the tools above |
Native tools in more detail
AWS: CloudWatch metrics and alarms, CloudWatch Synthetics canaries for scripted checks, Application Signals for service-level SLOs, and AWS Health for provider events.
Azure: Azure Monitor metrics and alerts, Application Insights availability tests from multiple regions, and Azure Service Health. Microsoft publishes its commitments in the SLA for Online Services.
Google Cloud: Cloud Monitoring with uptime checks, SLO monitoring and alerting policies based on error-budget burn.
How to choose the right tool
- Start from your SLAs. List each service, its commitment, the measurement window and who receives reports.
- Map your platforms. If almost everything runs on one cloud, native tools plus one external synthetic service are often enough. With two or more clouds, or heavy SaaS use, a cross-platform platform pays off.
- Check detection speed. Check intervals and alert latency must fit the downtime budget. Use one-minute checks for 99.9% and above.
- Test reporting. Ask for a sample monthly SLA report and check that it would stand up as evidence in a credit claim or customer review.
- Model the cost. Observability pricing depends on hosts, custom metrics, log volume and synthetic runs. Estimate a year of your data before signing.
- Decide who watches. A tool alone does not meet an SLA. Someone has to respond at 03:00. Compare running it in-house with a managed SLA monitoring service.
What Are the Best Practices for SLA monitoring?
- Monitor from outside and inside: external synthetics catch DNS, certificate and network problems, and internal metrics explain why.
- Alert on symptoms users feel (errors, latency, failed transactions), and use resource metrics for diagnosis rather than paging.
- Use burn-rate alerts on error budgets instead of single-threshold alarms to cut noise.
- Record maintenance windows and exclusions so reports match the contract wording.
- Review SLOs quarterly with business owners, and after major architecture changes.
- Keep incident timelines and logs long enough to support credit claims and audits.
Example: monitoring as part of the architecture
When SaaS recruitment platform WorkBuster moved to AWS with Opsio, near-zero downtime was critical because the platform is used around the world. The WorkBuster case describes an architecture built with CloudFormation. It runs EC2 instances in an auto-scaling group behind an Application Load Balancer, backed by multi-AZ MySQL RDS. CloudWatch dashboards and alarms are part of the design for operational excellence. The lesson for SLA monitoring: design availability and monitoring together, and keep monitoring as code next to the infrastructure.
How Opsio helps
Opsio's cloud monitoring and support services set up SLIs, SLOs, synthetic checks and alert routing on AWS, Azure and Google Cloud. A 24/7 team responds to alerts, and you get monthly SLA reports you can use in service reviews and credit claims.
Frequently asked questions
What is the best cloud SLA monitoring tool?
It depends on your estate. For a single cloud, the native tools (CloudWatch, Azure Monitor, Google Cloud Monitoring) plus an external synthetic check are often enough. For multi-cloud estates, observability platforms such as Datadog, Dynatrace or New Relic give one view with SLO reporting.
What is the difference between an SLA, an SLO and an SLI?
An SLA is the contract with consequences, such as service credits. An SLO is your internal target, usually stricter than the SLA. An SLI is the measurement itself, for example the percentage of successful requests.
Can I rely on my cloud provider's status page?
No. Status pages report broad incidents, often with delay, and do not show the impact on your application. Use them as one input alongside your own synthetic checks and request metrics.
How do I prove an SLA breach to claim credits?
Keep timestamped monitoring data and logs that show the failed requests or unavailability, and file the claim within the provider's deadline. For Amazon EC2, that is by the end of the second billing cycle after the incident, through AWS Support.
How often should SLA checks run?
Often enough to detect an outage well within your downtime budget. For targets of 99.9% and higher, run synthetic checks every minute from several locations.
Related reading: sla monitoring tools.
Related Articles
About the Author
Country Manager, Sweden
Johan leads Opsio's Sweden operations, driving AI adoption, DevOps transformation, security strategy, and cloud solutioning for Nordic enterprises. With 12+ years in enterprise cloud infrastructure, he has delivered 200+ projects across AWS, Azure, and GCP — specialising in Well-Architected reviews, landing zone design, and multi-cloud strategy.
Editorial standards: This article was written by a certified practitioner, named in the byline above. We revise it when the technology or regulation it covers changes; the dates above show the latest update. Opsio maintains editorial independence — we recommend solutions on technical merit, not commercial relationships.
