SLA Calculator
Calculate the maximum allowed downtime based on your SLA percentage.
Enter Your SLA
Table of Contents
Comprehensive SLA Guide
What is an SLA?
A Service Level Agreement (SLA) is a contract between a service provider and a customer that defines the expected level of service, typically expressed as a percentage of uptime. The SLA specifies the maximum amount of downtime allowed over a given period (day, month, or year) and often includes financial penalties or service credits if the provider fails to meet the guarantee. SLAs are common in cloud hosting, telecommunications, SaaS, and managed services.
How is downtime calculated?
The formula is: Downtime = (1 − SLA%) × Period. For example, with 99.9% SLA over one year (525,600 minutes): Downtime = 0.1% × 525,600 = 526 minutes (about 8.76 hours) per year. This calculator applies the same logic to daily, monthly, and yearly periods so you can see the maximum allowed outage in each window.
SLA vs SLO vs SLI
SLA (Service Level Agreement) is the contractual guarantee. SLO (Service Level Objective) is the internal target you aim for—typically set higher than the SLA to create a buffer. SLI (Service Level Indicator) is the actual metric you measure (e.g., availability percentage from monitoring). Good practice: set your SLO 0.5–1% above your SLA so that normal variation does not breach the agreement.
- Uptime %: The SLA percentage (e.g. 99.9%) is the guaranteed availability. The remainder is the allowed downtime.
- The "nines": 99% = two nines; 99.9% = three nines; 99.99% = four nines; 99.999% = five nines. More nines = less allowed downtime and usually higher cost.
- Service credits: Typical remedy for breach (e.g. 10–25% of monthly fee per 0.1% below SLA), not cash refunds.
- Exclusions: Scheduled maintenance, force majeure, and customer-caused outages are usually excluded from downtime.
Customer vs provider perspective
As a customer
- You get a clear uptime guarantee and credits if the provider fails.
- Use this calculator to see how much downtime your SLA allows (per day, month, year).
- Negotiate exclusions, measurement method, and credit caps in the contract.
- Higher SLA (e.g. 99.99%) usually costs more; balance against business impact.
As a provider
- You commit to a maximum downtime; exceeding it triggers credits or penalties.
- Set internal SLOs above the SLA to avoid breaching.
- Define precisely what counts as downtime and exclude scheduled maintenance.
- Monitor availability with the same methodology used in the contract.
Benefits of SLAs
- Clarity: Both parties agree on expected availability and consequences of failure.
- Accountability: Provider has an incentive to meet the target; customer has a defined remedy.
- Planning: Knowing max allowed downtime (e.g. 43 min/month for 99.9%) helps capacity and incident response planning.
- Trust: Published SLAs (e.g. cloud providers) support transparency and comparison.
Limitations and considerations
- An SLA is a guarantee of availability, not zero downtime. The allowed outage can still impact users.
- Service credits rarely cover consequential damages (lost revenue, reputation); liability caps apply.
- Definitions of downtime vary: partial outages, minimum duration, and exclusions must be clearly stated.
- Achieving five nines (99.999%) requires significant redundancy and cost; not all systems need it.
An SLA does not prevent outages—it defines how much downtime is allowed and what happens if the provider exceeds it. Always define what counts as downtime, how it is measured, and what is excluded (maintenance, force majeure). Service credits are typically capped and must be claimed within a short window; they do not replace business continuity planning.
Choosing the right SLA level
Selecting the appropriate SLA depends on business impact, cost, and feasibility. Consider:
- Criticality: What is the cost of one hour of downtime? Customer-facing revenue systems often need 99.9% or higher.
- Cost: Higher SLAs (99.99%, 99.999%) require redundancy and engineering; premiums can be significant.
- Industry norms: Cloud providers often offer 99.9–99.99%; telecom and finance may require five nines.
- Measurement: Ensure the contract specifies polling interval, locations, and how scheduled maintenance is excluded.
Quick reference: downtime by SLA
| SLA | Per Month | Per Year |
|---|---|---|
| 99% | 7.3 h | 3.65 days |
| 99.9% | 43.8 min | 8.76 h |
| 99.99% | 4.4 min | 52.6 min |
| 99.999% | 26 sec | 5.26 min |
SLAs set clear expectations for availability and provide a remedy when the provider falls short. Use this calculator to convert SLA percentages into concrete downtime limits (per day, month, year), and combine that with clear contract terms on measurement, exclusions, and service credits. For critical services, invest in monitoring and architecture that can actually meet the SLA you promise or require.
SLA Levels Explained
Typical SLA tiers and their implications. AWS, Azure, and GCP typically offer 99.9% to 99.99% depending on the service; five nines (99.999%) requires N+2 redundancy and is common in telecom and core banking.
99% – 99.5%
~7.3 h/month (99%) or ~3.6 h/month (99.5%). Suitable for non-critical internal tools, dev/staging. Low cost, less guarantee.
99.9% (three nines)
~43.8 min/month. Common for business apps, e-commerce, SaaS. Industry standard for many cloud providers.
99.99% (four nines)
~4.4 min/month. Critical systems, financial services, payment gateways. Requires redundant architecture.
99.999% (five nines)
~26 sec/month. Telecom-grade, mission-critical (e.g. 911, core banking). Very expensive to achieve and operate.
Downtime Reference Table
Use this table to see maximum allowed downtime per day, month, and year for common SLA levels. Values are derived from (1 − SLA%) × period in minutes.
| SLA | Per Day | Per Month | Per Year |
|---|---|---|---|
| 99% | 14.4 min | 7.3 h | 3.65 days |
| 99.9% | 1.44 min | 43.8 min | 8.76 h |
| 99.99% | 8.6 sec | 4.4 min | 52.6 min |
| 99.999% | 0.86 sec | 26 sec | 5.26 min |
Choosing and Negotiating SLAs
When defining or negotiating an SLA, focus on clarity and measurability. The following points help avoid disputes and ensure the agreement is enforceable.
- Define what counts as downtime (scheduled maintenance excluded? minimum duration?)
- Specify measurement: polling interval, locations, and how availability % is calculated
- Include service credits or penalties; typical 10–25% credit per 0.1% below SLA
- Require incident reporting and root cause analysis within 30 days
- Define what counts as downtime (scheduled maintenance excluded? Planned outages announced in advance?)
- Higher SLAs cost more - balance against business impact. A 1-hour outage may cost less than the premium for 99.99%.
- Include service credits or penalties in the contract. Typical: 10-25% credit per 0.1% below SLA.
- Require transparent incident reporting and root cause analysis (RCA) within 30 days.
- Consider separate SLAs for different service tiers (e.g., premium vs standard support).
- Specify measurement methodology: polling interval (1 min? 5 min?), number of monitoring points, geographic coverage.
- Avoid ambiguity: define "available" precisely (e.g., HTTP 200 within 5 seconds from at least 2 of 3 regions).
What Counts as Downtime?
SLA definitions vary by contract. To avoid disputes, clarify the following in writing:
- Scheduled maintenance: Usually excluded. Must be announced 5-14 days in advance.
- Force majeure: Natural disasters, wars - typically excluded.
- Customer-caused outages: Your misconfiguration - excluded.
- Partial outages: Some providers count only complete unavailability; degraded performance may not count.
- Minimum outage duration: Outages under 5 minutes may be excluded ("consumption" clauses).
- Third-party dependencies: Outages caused by upstream providers (cloud, CDN, DNS) may or may not count - clarify in the contract.
Service Credits and Penalties
When an SLA is breached, service credits are the typical remedy (not cash refunds). Example structure:
- 99.9% breached but ≥99.0%: 10% credit
- 99.0% breached but ≥95.0%: 25% credit
- <95.0%: 50–100% credit
Credits are usually capped (e.g. 100% of that month's fee). You must claim them within 30–60 days. Credits do not cover consequential damages (lost sales, reputation)—consider separate liability provisions for critical services.
SLA by Industry
Typical SLA expectations vary by sector. Use this as a reference when defining or negotiating your own SLA.
- E-commerce / retail: 99.9-99.95%. Every minute of downtime during peak (Black Friday, Christmas) can mean thousands in lost revenue.
- Healthcare / HIPAA: 99.99% or higher for patient-facing systems. Regulatory pressure and patient safety drive strict requirements.
- Banking / fintech: 99.99-99.999%. Payment processing and core banking often require five nines. Transaction systems must be highly available.
- SaaS / B2B: 99.9% is common baseline; enterprise customers often negotiate 99.95% or 99.99% with premium support.
- Internal IT / dev tools: 99% may suffice for staging, CI/CD, internal dashboards. Business impact is lower than customer-facing systems.
Monitoring and SLA Compliance
To track SLA compliance you need consistent measurement and clear definitions. The following practices help avoid disputes and support accurate reporting.
- Uptime monitoring from multiple geographic points (avoid false positives from a single location)
- Consistent polling interval matching the SLA definition (e.g. 1-minute checks)
- Accurate incident logging with start/end timestamps for availability calculation
- Exclusion of scheduled maintenance; ensure monitoring respects maintenance windows
- Transparent reporting: status pages and monthly availability reports
Multi-region or multi-service SLAs: If you depend on several components (API, database, CDN), each with 99.9%, the combined availability is lower. Example: API 99.9% × DB 99.9% ≈ 99.8% end-to-end. Design for redundancy and failover to avoid compounding failures.