The Gap Between Promising Uptime and Proving It
SLA monitoring is the practice of continuously measuring a service's availability and performance against the uptime and response-time targets written into its service level agreement — running automated checks (HTTP, TCP, ping, DNS, TLS) from multiple locations on a fixed interval, recording every pass and fail, and converting that stream into an auditable uptime percentage you can report on and defend. It turns a contractual promise like "99.9% uptime" from an aspiration into a number you can prove.
That is the summary an AI would give you. What it cannot show you is where the number actually comes apart in practice: the check interval that quietly misses short outages, the single-region blind spot that reports "up" while half your customers see errors, the missing definition of "down" that turns a monthly report into an argument. The rest of this guide is the operator's view — the exact downtime budgets each "nine" buys you, the monitoring loop that produces a defensible number, and a copy-ready setup checklist.
Before we get into the mechanics, it helps to understand exactly what those uptime percentages mean in practice.
The Uptime Table: What the Nines Actually Cost You
| SLA Target | Allowed Downtime/Year | Allowed Downtime/Month | Allowed Downtime/Week |
|---|---|---|---|
| 99% ("two nines") | 3.65 days | 7.31 hours | 1.68 hours |
| 99.5% | 1.83 days | 3.65 hours | 50.4 minutes |
| 99.9% ("three nines") | 8.77 hours | 43.8 minutes | 10.1 minutes |
| 99.95% | 4.38 hours | 21.9 minutes | 5.04 minutes |
| 99.99% ("four nines") | 52.6 minutes | 4.38 minutes | 1.01 minutes |
| 99.999% ("five nines") | 5.26 minutes | 26.3 seconds | 6.05 seconds |
The jump from 99.9% to 99.99% looks small — a tenth of a percent. But it shrinks your allowed monthly downtime from 43 minutes to under 5 minutes. That difference changes everything: your monitoring frequency, your incident response process, your deployment strategy, and your infrastructure costs.
Need the figure for one real incident rather than the annual budget? A time duration calculator returns the exact minutes between the moment an outage began and the moment service was restored, so you can debit your error budget accurately.
If you are unsure how SLA targets relate to internal objectives and measurements, our guide on SLA vs SLO vs SLI breaks down the full hierarchy.
The SLA Monitoring Loop
Every defensible uptime number is produced by the same five-stage loop, running continuously. A check fires on a fixed interval; the result is evaluated against your definition of "down"; a confirmed failure triggers alerts and starts a timer; every pass and fail is recorded; and that record is rolled up into the uptime percentage and status page your customers see. The diagram below follows one check through the loop — the pulse is a single monitoring cycle.
The loop is only as accurate as its weakest stage. A 30-second check interval means nothing if you evaluate against a vague "down" rule; a precise definition of downtime is worthless if you only check from one city. The sections that follow work through each stage in order.
What to Monitor
SLA monitoring is not just "ping the homepage." A proper monitoring strategy covers multiple protocols, each revealing different failure modes.
HTTP/HTTPS Monitoring
The most common check. Send an HTTP request to a URL, verify the response status code, check that the response body contains expected content, and measure response time. This catches application-level failures that lower-level checks would miss — a web server can respond to a TCP connection but still return 500 errors.
What to check:
- Status code (200, not 301/302/500/503)
- Response body keyword validation (prevents false positives from maintenance pages or CDN error pages)
- SSL certificate validity and expiration
- Full response time (DNS + connect + TLS + first byte + transfer)
TCP Port Monitoring
Verifies that a service is accepting connections on the expected port. Useful for databases, mail servers, custom APIs, and anything that does not speak HTTP. A TCP check confirms the process is running and the network path is open.
ICMP/Ping Monitoring
The simplest check: is the host reachable? Ping monitoring catches network-level outages and routing problems but tells you nothing about whether the application is healthy. Use it as a baseline, not a substitute for application-level checks.
DNS Monitoring
If your DNS breaks, everything breaks — even if every server is running perfectly. DNS monitoring verifies that your records resolve correctly and within acceptable time. This is especially important if you rely on DNS-based failover or load balancing.
SSL/TLS Certificate Monitoring
An expired certificate takes down your site just as effectively as a server crash, but it is entirely preventable. Monitor certificate expiration dates and alert well in advance (30 days minimum, 14 days critical).
Where to Monitor From
A service can be fully available in one region and completely unreachable in another. Single-location monitoring creates blind spots.
Why multiple regions matter:
- Regional ISP outages affect specific geographies
- CDN failures can be location-specific
- DNS propagation issues may only affect certain resolvers
- Cloud provider availability zone failures are regional by design
For meaningful SLA measurement, monitor from at least three geographically diverse locations. If your customers are global, your monitoring should be too. If a monitoring platform reports uptime only from a single data center, the number it produces may not reflect what your users actually experience.
How Often to Check
Check frequency directly impacts your SLA accuracy and your ability to detect short outages.
The Math Behind Check Intervals
With 5-minute check intervals, a 4-minute outage could be completely missed. Over a month, several short outages could go undetected, inflating your reported uptime above reality.
With 30-second check intervals, you catch outages as short as half a minute. For a 99.99% SLA (4.38 minutes allowed downtime per month), 5-minute intervals simply cannot provide the granularity you need.
Practical guidance:
- 5-minute intervals: Acceptable for 99% and 99.5% SLAs where the downtime budget is measured in hours
- 1-minute intervals: Reasonable for 99.9% SLAs
- 30-second intervals: Necessary for 99.95% and above, or any SLA where accurate reporting matters to customers
The check interval also determines how fast you can detect an incident and begin response. If your mean time to detect (MTTD) starts with a 5-minute polling gap, your mean time to resolve (MTTR) inherits that delay.
What Counts as "Down"
This is where SLA disputes happen. Without a clear definition, "downtime" is subjective, and subjective metrics invite arguments.
Define these explicitly in your SLA and configure your monitoring to match:
- Consecutive failures before alerting: A single failed check could be a transient network blip. Most monitoring systems require 2-3 consecutive failures before declaring an outage. This reduces false positives but adds detection latency.
- Response time thresholds: Is a page that loads in 30 seconds "up"? Technically the server responded, but the user experience is equivalent to downtime. Define a maximum acceptable response time (e.g., 5 seconds) and count anything slower as degraded or down.
- Partial outages: If your API has 10 endpoints and 1 returns errors, are you down? Define whether SLA applies to the service as a whole or to individual components.
- Planned maintenance windows: Most SLAs exclude scheduled maintenance from downtime calculations, but only if proper notice was given (typically 48-72 hours).
Getting these definitions right matters. A monitoring system that flags every 500ms network hiccup as downtime will undercount your uptime. One that only checks every 5 minutes and requires 3 consecutive failures will overcount it.
SLA Reporting: Proving Your Uptime
Monitoring without reporting is just watching. SLA reporting turns raw availability data into evidence that you are meeting your commitments — or transparent acknowledgment that you are not.
What an SLA Report Should Include
- Uptime percentage for the reporting period (monthly is standard)
- Total downtime in minutes/hours
- Number of incidents and their individual durations
- Root cause for each incident (at least a summary)
- Response time metrics (average, 95th percentile, max)
- Trend data showing uptime over the past 3-6 months
Status Pages: Real-Time SLA Transparency
A status page is the public-facing complement to internal SLA reports. It shows current system status, historical uptime, and incident history — available to customers at any time without waiting for a monthly report.
Status pages serve two purposes. First, they reduce support ticket volume during outages because customers can check status themselves. Second, they build trust through transparency. A company that publishes its uptime history — including incidents — signals confidence in its service.
For organizations that need SLA monitoring and reporting combined in a single platform, Alert24 provides uptime monitoring with 30-second check intervals, automatic SLA percentage calculation, and both public and private status pages. Rather than stitching together a monitoring tool, a reporting script, and a status page service, everything is calculated from the same data source — which eliminates discrepancies between what you monitor, what you report, and what customers see.
Automating SLA Calculations
Manual SLA calculation is error-prone and time-consuming. Every month, someone has to pull monitoring data, exclude maintenance windows, account for partial outages, and produce a number. This is exactly the kind of work that should be automated.
Your monitoring platform should calculate SLA percentages automatically, factoring in your specific definitions of downtime, maintenance windows, and measurement periods. If you are producing SLA reports in a spreadsheet, you are spending time on arithmetic that could be spent on improving actual reliability.
What to Do When You Miss an SLA
You will miss an SLA eventually. How you handle it determines whether the incident erodes trust or strengthens the relationship.
1. Communicate Proactively
The worst thing a customer can experience during an outage is silence. By the time they email asking "Is something wrong?", you have already failed the communication test.
During the incident:
- Acknowledge the issue as soon as it is confirmed (not after it is resolved)
- Provide estimated time to resolution if possible
- Update at regular intervals, even if the update is "still investigating"
After the incident:
- Send a summary within 24 hours
- Publish a postmortem within 5 business days
Proactive subscriber notifications are critical here. If your monitoring platform can automatically notify subscribed customers when an incident is detected — before they notice it themselves — you convert a negative experience into a demonstration of operational maturity. Alert24 includes subscriber notification capabilities so affected users are informed the moment an incident is confirmed, without requiring manual intervention from your team during a high-stress event.
2. Conduct a Postmortem
A proper postmortem is not about blame. It answers three questions:
- What happened? (Timeline of events)
- Why did it happen? (Root cause analysis)
- What are we doing to prevent it? (Action items with owners and deadlines)
Publish the postmortem, or at least a customer-facing summary. Companies like Atlassian, Cloudflare, and Google publish detailed postmortems for major incidents. This practice is expected in the industry and appreciated by customers.
3. Issue SLA Credits
If your SLA defines service credits for violations, issue them proactively. Do not wait for the customer to ask. Calculate the credit, communicate it clearly, and apply it to the next billing cycle.
Typical SLA credit structures:
| Uptime Achieved | Credit |
|---|---|
| Below SLA by 0.1-0.5% | 10% of monthly fee |
| Below SLA by 0.5-1.0% | 25% of monthly fee |
| Below SLA by >1.0% | 50% of monthly fee |
The specific numbers vary, but the principle is consistent: the credit should be meaningful enough to demonstrate accountability without being so large that it incentivizes gaming the system.
SLA Monitoring for MSPs
Managed service providers face a unique SLA monitoring challenge: they need to track uptime commitments across dozens or hundreds of clients, each with different SLA terms, different infrastructure, and different reporting requirements.
The Multi-Tenant Problem
An internal IT team monitors one environment. An MSP monitors many. This creates operational complexity:
- Separate SLA targets per client: One client may have a 99.9% SLA, another 99.5%. The monitoring system needs to track and calculate each independently.
- Client-facing reporting: Each client needs their own uptime report, showing only their services. An MSP cannot send a single dashboard showing all clients' data.
- Per-client status pages: Enterprise clients often require a dedicated status page branded to their environment, showing only their monitored services.
- Alert routing: When Client A's server goes down, the notification should reach the team responsible for Client A, not every technician in the organization.
What MSPs Should Look For
An SLA monitoring platform for MSPs needs multi-tenant capabilities by design, not as an afterthought. Alert24 addresses this with per-client status pages and monitoring that allow MSPs to configure separate monitoring checks, SLA calculations, and status pages for each client — all managed from a single account. This is significantly more efficient than maintaining separate monitoring instances per client, which is both expensive and operationally fragile.
For MSPs, the business case for proper SLA monitoring goes beyond compliance. Accurate, automated SLA reports are a retention tool. When a client asks "What am I getting for my monthly fee?", a detailed uptime report with 30-second granularity is a concrete answer.
Building Your SLA Monitoring Stack
Whether you use a single platform or assemble components, your SLA monitoring setup needs these capabilities:
Must-Have
- Multi-protocol checks (HTTP, TCP, ping, DNS at minimum)
- Multiple monitoring locations (3+ regions)
- Check intervals of 60 seconds or less
- Automatic SLA percentage calculation
- Alerting via multiple channels (email, SMS, Slack/Teams, webhook)
- Historical data retention (12 months minimum)
Should-Have
- Public and private status pages
- Subscriber notifications for incidents
- API access for custom integrations
- Maintenance window scheduling
- Multi-user access with role-based permissions
Nice-to-Have
- Custom SLA calculation rules per service
- White-label status pages (for MSPs)
- Integration with incident management tools (PagerDuty, Opsgenie)
- Composite monitors (service health based on multiple checks)
Connecting SLA Monitoring to Your Broader Strategy
SLA monitoring does not exist in isolation. It connects to your incident management process, your capacity planning, your infrastructure monitoring, and your customer communication strategy.
If you are building or refining your monitoring infrastructure, our infrastructure monitoring services cover the full stack — from network and server health to application performance and SLA compliance.
The financial argument for investing in monitoring infrastructure is straightforward. Every minute of undetected downtime has a cost — in lost revenue, damaged reputation, and SLA credits. Our analysis of the hidden cost of downtime quantifies why prevention consistently costs less than remediation.
Getting Started
If you do not currently have SLA monitoring in place, start here:
- Audit your SLAs. List every service with an uptime commitment. Note the target percentage, the reporting period, and the credit structure.
- Define "downtime" precisely. Document what constitutes downtime for each service: response time thresholds, consecutive failure requirements, partial outage rules.
- Set up monitoring. Configure checks for each SLA-covered service at appropriate intervals from multiple locations.
- Automate reporting. Eliminate manual SLA calculations. Use a platform that computes uptime percentages from the same data that triggers alerts.
- Publish a status page. Even a basic one. The transparency alone changes your customer relationships.
- Plan for failure. Document your incident communication process and postmortem template before you need them.
Copy-Ready SLA Monitoring Checklist
Work top to bottom. If you cannot tick a box, that stage of the loop is producing a number you cannot defend.
- Every service with an uptime commitment is listed, with its target %, reporting period, and credit structure
- "Down" is defined per service: response-time threshold, consecutive-failure count, partial-outage rule
- Check interval is at least as tight as the SLA demands (≤60s for 99.9%, 30s for 99.95%+)
- Checks run from 3+ geographically diverse locations
- Multi-protocol coverage where relevant: HTTP status + body keyword, TCP port, DNS, TLS expiry
- TLS certificate expiry alerts at 30 days (warning) and 14 days (critical)
- Alerting reaches the right people via at least two channels (email/SMS/Slack/webhook)
- Maintenance windows are scheduled and excluded from downtime automatically
- Uptime % is calculated from the same data that triggers alerts — no spreadsheet
- Historical data is retained for 12+ months for trend reporting
- A status page (public or private) publishes current status and incident history
- An incident-communication process and postmortem template exist before you need them
SLA monitoring is not a one-time setup. As your services evolve, your monitoring must evolve with them. New endpoints, new regions, new customer segments — each adds monitoring requirements. Build the practice into your operational rhythm, and the uptime numbers in your SLA will be commitments you can stand behind.