At 10:17 a.m., your checkout pages time out, support tickets surge, and your team opens a provider incident ticket. The VPS may return within minutes. Yet DNS, validation, and customer access can take hours.
SLA credits rarely cover recovery loss
An SLA credit is a billing remedy, not payment for business losses. Providers may credit 10% to 100% of the affected monthly charge. You still absorb lost profit, idle payroll, emergency labor, refunds, and missed deadlines.
A 100% monthly credit on a $300 cloud bill is worth $300. If the outage costs $2,000 per hour, recovery takes four hours. The business loss is $8,000. The credit covers 3.75% of that loss.
Calculate the hourly outage cost
Measure the work that stops, not only lost online sales.
Hourly outage cost = lost gross profit + idle staff cost + recovery labor + penalties/refunds + estimated future churn.
A monthly uptime percentage measures provider-defined availability. It does not measure the time until your application works again. At 99.9%, allowed downtime is roughly 43 minutes per 30-day month. At 99.99%, it is about 4 minutes and 19 seconds.
A VPS may return in 20 minutes. Database recovery, DNS, validation, or payment integrations can still keep checkout unavailable.
A complete SLA needs more than an uptime percentage and a credit table. It should name the covered service and monitoring method. It should also state the measurement window and exclusions.
Those exclusions may include planned maintenance, third-party networks, customer configuration, or force majeure events. The SLA should also separate support response from resolution. An acknowledgment within 30 minutes does not promise managed VPS recovery within 30 minutes.
The gap between credit and loss can be huge.
Ask if brief incidents are combined for claims. Ask if partial degradation counts as downtime. Also ask whether DNS, storage, databases, and network layers are measured separately.
These details determine whether service level agreement credits can be triggered. They matter when a customer-facing service fails.
Your recovery clock starts before downtime ends
Actual recovery time begins when the business detects failure. It ends when critical work is reliably usable again. That includes detection, ticket routing, diagnosis, restoration, validation, and normal operations.
RTO, RPO, and MTTR are different
Recovery Time Objective (RTO) is the target maximum time to restore service. Recovery Point Objective (RPO) is the maximum acceptable data loss. Mean Time to Recovery (MTTR) usually measures average repair time.
An RTO of two hours sets a two-hour restoration target. An RPO of 15 minutes allows no more than 15 minutes of lost data.
Map the full return-to-work timeline
Track these timestamps during every meaningful incident.
- Detection: Synthetic monitoring, an employee, or a customer identifies the failure.
- Ticket opened: The issue reaches the provider's documented support channel.
- Provider acknowledgment: An incident owner confirms active handling.
- Technical restoration: The host, database, network, or storage service returns.
- Validation: Test login, checkout, API calls, email, permissions, and data integrity.
- Business return: Staff and customers can complete critical tasks normally.
A successful claim needs a defensible incident response timeline. A screenshot of an unavailable page is not enough. Keep alerts from more than one location.
Keep application and load-balancer logs, provider notices, ticket IDs, and support-chat transcripts. Store all timestamps in one time zone. Record the first user failure and provider acknowledgment.
Also record technical restoration and confirmed testing. Testing should confirm DNS recovery, database restoration, and normal transactions.
The real recovery clock ends after business validation.
Compare this record with SLA exclusions and the claim deadline before filing. The same evidence shows real outage costs. It also helps improve an SMB disaster recovery plan after the incident.
Compare providers by proven recovery evidence
Choose cloud hosting, a managed VPS, or a multi-region platform using tested recovery evidence. Do not choose only by the highest advertised uptime number.
A high uptime rate can limit provider-defined downtime. It cannot prove that your business will recover within its RTO. Ask for restore tests, failover results, and support escalation details. Match those results to your own RTO and RPO. A credit table matters less when checkout, client files, or an API stays unavailable for hours.
Compare loss exposure, not just price
Set RTO and RPO from your own loss tolerance. Do not copy them from a vendor marketing page.
| Business type | Likely priority | Target RTO | Target RPO | Credit rarely covers |
|---|
| Ecommerce store | Checkout and orders | 30 to 60 minutes | 5 to 15 minutes | Lost gross profit and ad spend |
| Professional services | Client access and files | 2 to 4 hours | 1 to 4 hours | Idle payroll and missed billable work |
| SaaS business | Application and API | 30 to 90 minutes | 5 to 30 minutes | Churn, credits, and support load |
| Clinic portal | Scheduling and records | 1 to 2 hours | 15 to 60 minutes | Rescheduling and compliance exposure |
Ask for proof before signing
Ask for recent disaster-recovery test results and restore timing. Ask for support escalation paths and root cause analysis commitments. Also ask about claim deadlines.
Check the scope for databases, storage, DNS, load balancers, and secrets. A provider may cover one layer but exclude another.
SLA credits are not a priority for a noncritical site. That site can stay offline without material impact. It also stores no meaningful transaction data. Credits do not replace compliance, cyberinsurance, or liability review. These considerations apply to regulated businesses, including healthcare and financial services.
Before signing, check if cloud service credits are the sole and exclusive remedy. That wording may block other contractual remedies. This can happen even when downtime losses exceed the monthly fee.
For critical workloads, seek a defined escalation path and recurring-incident review. Seek root-cause analysis delivery after material failures. Also seek exit rights or service-fee relief.
A provider may reject uncapped liability for lost revenue. An SMB can still seek practical protections. These include shorter notice requirements, clearer outage definitions, migration assistance, and termination rights.
Verified recovery performance should guide the final choice.
Common questions
Are SLA credits enough for SMB downtime?
No. They usually apply only to the monthly bill. They exclude lost sales, labor, and reputational damage.
Does 99.9% uptime mean recovery takes 43 minutes?
No. It permits about 43 minutes of monthly downtime. It does not guarantee a 43-minute recovery.
What is the difference between RTO and RPO?
RTO is the target restoration time. RPO is the maximum acceptable amount of lost data.
How do I calculate the cost of an outage?
Add lost gross profit, idle payroll, recovery labor, refunds, penalties, and estimated churn. Calculate these costs for each outage hour.
Can a backup meet my recovery requirement?
Only if a restore test returns usable data within your stated RTO and RPO. A backup alone does not prove recovery speed.
What evidence do I need for an SLA claim?
Keep monitoring data, timestamps, ticket numbers, provider notices, logs, and screenshots. File the claim within the contract deadline.
The essential points:- Service credits usually offset a future bill, not the economic harm of a long outage.
- Measure actual recovery time from first detection through validated return to normal business operations.
- Set RTO and RPO from hourly loss tolerance. Then require proof through restore and failover tests.
- Choose providers using recovery evidence, exclusions, escalation terms, and claim records alongside uptime guarantees.
Learn more
Here are some additional resources on this subject:
