An uptime SLA, or service level agreement, sets the provider’s promise for how often its service will be available. Before signing, review how downtime is measured, excluded, and compensated, then compare those terms with the customer commitments your business must keep.
A headline percentage alone isn’t an enforceable uptime guarantee or a clear remedy for lost revenue, idle staff, and customer frustration.
The contract needs clear ownership alongside its promises.
Start by translating the percentage into time your business could lose.
Key Takeaways Before You Sign
- A 99.9% uptime commitment allows roughly 44 minutes of monthly downtime, before contractual exclusions.
- A service credit rarely equals compensation for business loss. Calculate the actual remedy before treating it as protection.
- Availability, recovery speed, and acceptable data loss are separate commitments.
- Assign a business owner and technical owner, then test your fallback before the service becomes critical.
Translate Your SaaS Uptime SLA Into Downtime
Put the percentage on a calendar
A 99.9% uptime target allows 43.8 minutes per month, while 99.99% uptime allows 4.38 minutes. These figures use an average month across a 365-day year. The uptime percentage you receive depends on the contract’s measurement window.
A fixed 30-day month gives slightly different allowances:
| Uptime target | Downtime in 30 days | Downtime across 365 days |
|---|---|---|
| 99% | 7.2 hours | 3.65 days |
| 99.9% | 43.2 minutes | 8.76 hours |
| 99.95% | 21.6 minutes | 4.38 hours |
| 99.99% | 4.32 minutes | 52.56 minutes |
The annual figures are conversions, not permission to pool outage minutes across months. The contract’s measurement period determines the monthly uptime percentage used to assess a breach.
Calculate the measured result
The standard formula is:
Monthly uptime percentage = (Maximum Available Minutes minus Downtime) / Maximum Available Minutes x 100.
Uptime.com’s worked example uses 43,200 minutes in a 30-day month. With 43,105 available minutes, the service interruption totals 95 minutes. That monthly uptime percentage is approximately 99.78%, below a 99.9% commitment.
Once you know the uptime percentage, connect those minutes to business exposure. Our system-to-revenue mapping worksheet helps you identify which outages interrupt revenue and operations.
An expense tool and an ordering platform don’t need identical protection. Your business priorities should determine the threshold.
Define What Counts as an Outage
Measure the customer experience
A service can be technically reachable while customers cannot complete their work. Technical availability doesn’t guarantee customers can use the service.
Your software platform evaluation should define whether downtime includes failed transactions, unavailable APIs, broken authentication, or severe performance degradation. For multi-tenant software, identify which production environments, regions, and subscription tiers receive coverage.
Confirm monitoring for multi-tenant services reflects your tenant’s experience, not a broader platform average. A shared-platform average can hide a tenant-specific failure on a multi-tenant system.
Specify whose monitoring supplies the evidence and how disputed measurements are resolved.
Read the measurement window and exclusions
Monthly and annual commitments produce different results. Four hours of downtime would remain above 99.9% across a year. In a 30-day month, four hours would fall well below that threshold.
Review all exclusions alongside the outage definition. Require clear boundaries, notice requirements, and limits on planned maintenance, including its duration.
Keep a separate measure of business-impacting incidents, including those the contract excludes.
An excluded outage can leave the vendor within its SLA while your business still misses its customer promise.
That distinction belongs in your vendor risk management and operating reports.
Compare Real Commitments and Service Credits
Read the provider-specific terms
Provider names and percentages don’t tell the whole story. Compare the remedy and claim process alongside the headline availability commitment.
These published terms show the differences:
| Provider | Commitment | Remedy and claim terms |
|---|---|---|
| Sitecore SaaS | At least 99.90% monthly | 10% credit below 99.90% but at least 98%; 20% below 98%. Claim within 10 days after month-end. |
| Dynatrace SaaS | 99.5% Standard Support; 99.95% Enterprise Success and Support | Formula-based credits, capped at 10% of affected annual subscription spend. Claim within 30 days of unavailability. |
Sitecore’s SaaS SLA requires at least 48 hours’ notice for planned maintenance. Credits apply against future fees and are the sole remedy.
For comparison, the Google Cloud Run SLA lists 99.95% for non-GPU services outside Stockholm, roughly 22 monthly downtime minutes. Stockholm’s commitment differs. An infrastructure SLA doesn’t automatically become your SaaS application’s availability commitment.
Calculate the credit on an actual fee
Dynatrace’s SaaS SLA provides a direct example: a $1,000 monthly fee, 99.5% commitment, and 95% measured uptime produce:
$1,000 x (99.5% minus 95%) = $45.
A service credit isn’t a refund or other payment, and you must submit a claim. The claim requires a support ticket with the dates, times, and affected environment URL.
That $45 is the contractual remedy. Your lost sales and recovery effort require separate analysis. Never assume a missed commitment produces an automatic credit.
Separate Availability From Disaster Recovery
Set recovery limits in business terms
The recovery time objective (RTO) states how quickly service should return. The Recovery Point Objective (RPO) states how much data loss, measured in time, is acceptable.
Your business owner sets the tolerance. Your technical owner explains the cost and delivery requirements.
Sitecore describes best-efforts recovery targets of a 24-hour RPO and a three-working-day RTO, with backups replicated to a paired cloud region. These targets differ from its monthly availability commitment.
If your customer promise requires recovery within an hour, a multi-day recovery target leaves a material gap.
Require evidence of recoverability
Disaster recovery planning needs more than a statement that backups exist. Request restore-test results, achieved recovery times, and evidence that the complete service, not just the application, can be restored.
Map dependencies such as identity, payments, hosting, and data feeds. The contract should state which party coordinates recovery when suppliers are involved.
Our lessons from the AWS outage connect those dependencies with business continuity decisions.
For hosted software, source code alone cannot restore service. Contract for usable data exports, schemas, integration documentation, and transition assistance. Test whether exported data can be imported elsewhere.
Negotiate the Terms That Change Your Exposure
Service commitments matter commercially. AWS’s account of the IDC SaaSPath 2020 survey reports that guaranteed service levels led to increased SaaS investment among 1,915 surveyed organizations. That historical finding doesn’t make every guarantee valuable.
An uptime guarantee is a headline promise; the uptime SLA makes it enforceable through clear measures, exclusions, and remedies. Use this checklist to review the SLA before signing:
- Define the critical customer workflow and the longest disruption your business can tolerate.
- Confirm covered services, uptime measurement methods, exclusions, maintenance windows, and dependencies on third parties.
- Set incident notification triggers, escalation contacts, update frequency, and responsibility for customer communications.
- Require availability reports and supporting evidence. Calculate service credits, caps, claim deadlines, and remedies for chronic failures.
- Agree on recovery targets, test evidence, data-return obligations, and an executable exit path.
For a material provider, propose incident notification within 24 hours after discovery, followed by updates at agreed intervals. Treat this as a negotiated target, not a universal legal deadline.
Have counsel assess the SLA’s sole-remedy language alongside liability limits, termination rights, and other negotiated protections. A service credit clause doesn’t answer every contractual question.
If stronger availability costs more, compare the premium with your own outage exposure. Technology spend optimization includes paying for protection where the business case supports it.
Give the Commitment an Owner After Signing
A signed SLA needs an operating rhythm.
Assign one accountable business owner and one technical owner. The business owner tracks customer and financial consequences. The technical owner maintains monitoring, evidence, escalation, and recovery readiness.
Review performance alongside spend, capacity, dependencies, and customer impact. Repeated misses require corrective action, a tested workaround, or a replacement decision.
For board-ready reporting, show the service, business exposure, recent failures, recovery-test results, owner, and decision required. Our guidance on board-ready cybersecurity risk reporting connects technical conditions with operational consequences.
Where a technology leadership gap leaves these decisions scattered, a fractional CTO or interim CTO can coordinate the review. Your internal accountability should remain clear.
Keep claim deadlines in the same process. A short filing window is easy to miss during incident recovery.
Frequently Asked Questions About SaaS Uptime SLAs
Is 99.99% uptime good?
It allows about 52.56 minutes of downtime annually, or 4.38 minutes in an average month. Whether it’s sufficient depends on covered functions, exclusions, recovery capability, and your customer commitments.
What is a reasonable uptime commitment?
Choose a threshold that supports the business process. Compare outage cost, available workarounds, and the premium for stronger availability. A higher percentage has limited value if essential transactions fall outside its definition.
Does an uptime commitment guarantee business continuity?
No. It defines measured availability and the consequences of missing it. Business continuity also needs recovery capability, usable data, supplier coordination, and tested workarounds.
What should happen after repeated SLA failures?
Escalate beyond individual credit claims. Require a corrective plan with owners and deadlines. Use negotiated termination or transition rights when the provider cannot meet your business requirements.
Sign When the Business Tradeoff Is Clear
Before signing, you should be able to explain the downtime allowance, actual remedy, recovery gap, and accountable owners. The strongest SaaS uptime SLA is one your team can measure and manage.
If those answers remain scattered, Get an Executive Technology Clarity Check to identify the priorities and ownership your decision needs.
Your goal is a defensible business decision, backed by terms and recovery capabilities that support the promise you make to customers.