A 99.9% uptime promise can sound safe until an outage stops orders, client work, or internal operations. The provider may offer a credit worth less than one hour of business loss. The real gap comes from exclusions, narrow coverage, and short claim deadlines.
Hidden SLA and Uptime Pitfalls for SMBs can leave firms with hours of disruption and a small credit. That credit may be capped at one affected resource's monthly fee. Compare outage cost with the credit cap before you buy, renew, migrate, or file a claim.
Why a 99.9% SLA rarely pays for an outage
A 99.9% uptime guarantee rarely pays for a real SMB outage. It often covers only the monthly fee for the failed resource.
How much downtime does each tier allow?
The measurement period changes the meaning of every uptime promise. In a 30-day billing cycle, 99.9% allows about 43.2 minutes of downtime.
A 99.95% SLA allows 21.6 minutes in 30 days. A 99.99% SLA allows 4.32 minutes.
| Monthly uptime promise | Downtime allowed in 30 days | What to verify |
|---|
| 99.9% | 43.2 minutes | Whether maintenance is excluded |
| 99.95% | 21.6 minutes | Whether the SLA is monthly or annual |
| 99.99% | 4.32 minutes | Which service layer is measured |
| 99.999% | 26 seconds | Whether this applies to your architecture |
When does a credit become meaningful?
A credit matters only when its maximum value approaches your likely loss. A 100% credit on a $100 VPS remains only $100.
This is still true if a four-hour failure costs $8,000 in sales and support labor.
Use this test before buying: Multiply average hourly revenue by likely outage duration. Then compare that result with the largest credit for the affected service. If one outage hour costs $3,000 and the maximum credit is $300, the SLA is not financial protection. It is a billing concession.
The percentage matters less than the cap.
Why your app can be down while the SLA still passes
A provider can meet its infrastructure SLA while your business remains inaccessible. The contract may cover a server or network, not your working app.
What availability does the SLA cover?
An SLA is a contract remedy. A Service Level Objective, or SLO, is a performance target set by your own team.
A provider can offer 99.99% server uptime. Your own SLO may require 99.95% successful checkout transactions.
- Network uptime: The provider network passes traffic, but your server can still fail.
- Server uptime: A VPS or dedicated server responds, but the web app can return errors.
- Managed database availability: The database responds, but the app can have bad queries or expired credentials.
- Application availability: Users complete a defined business action. This is usually what your SMB needs.
A provider status page offers useful evidence, but it cannot prove your app was available. It reports the provider's services, not necessarily a shopper's experience in California.
External monitoring from more than one location is essential.
Major cloud documents and incident practices support external monitoring from multiple locations. Test Northern Virginia, Oregon, Iowa, California, and Texas when those areas match your traffic.
Monitor a real transaction, not only an HTTP ping. A synthetic checkout, login, or API test can reveal failures that a “200 OK” response misses.
A reachable IP address is infrastructure availability. A completed customer transaction is business availability. An SLA may cover the first, while your company needs the second.
For cloud services, compare public terms for the exact product. AWS, Microsoft Azure, and Google Cloud publish separate terms for compute, storage, databases, and zones.
The Uptime Institute also separates facility resilience from a customer application's availability. That distinction changes whether a credit applies after an app outage.
Compare outage cost with the maximum SLA credit
Compare your hourly outage cost with the maximum recoverable credit. Use the exact resource that failed.
What does one outage hour cost?
Hourly outage cost starts with lost gross profit or revenue. It should also include costs caused by the outage.
Count paid clicks that hit error pages, support tickets, agency emergency work, and contract penalties. These costs can exceed lost sales during a short outage.
| SMB operation | Example loss per hour | Affected monthly fee | Maximum 100% credit | Gap after one hour |
|---|
| Ecommerce store | $4,000 to $12,000 | $400 instance | $400 | $3,600 to $11,600 |
| B2B SaaS | $2,000 to $6,000 | $1,200 stack | $1,200 | $800 to $4,800 |
| Digital agency | $800 to $2,500 | $300 VPS | $300 | $500 to $2,200 |
| Local lead business | $300 to $800 | $150 shared plan | $150 | $150 to $650 |
Which fee does the credit percentage use?
The credit percentage may apply to one instance, one availability zone, or one product SKU. It may not apply to your whole account invoice.
Proration means the provider calculates the credit against a narrowly defined affected charge. That wording can sharply reduce the payout.
Cloud hosting across two availability zones can reduce exposure. Your app, database, DNS, and failover logic must all use both zones.
A single healthy component cannot save a broken customer journey.
Because availability needs vary, different SMBs need different targets and fallback plans. Ecommerce firms with paid campaigns may treat checkout failure as urgent.
They can use transaction monitoring, a cached catalog, alternate payments, and a tested rollback path. A 99.9% SLA may fail them during peak sales periods.
A B2B SaaS firm may set an SLO for successful logins and core API requests. It should also prepare a status page, read-only mode, and customer communication runbook.
Agencies should separate client environments and keep recent backups with deployment rollback access. Local lead firms may need call forwarding and offline appointment access.
For an SMB, compare outage cost per hour with the exact credit cap before signing. Credits offset bills, but they rarely cover business loss.
Find exclusions and proration before you sign
The most damaging SLA terms are exclusions, vague downtime definitions, and per-resource proration. Read them before you accept the contract.
Which exclusions erase a valid claim?
Scheduled maintenance, emergency maintenance, force majeure, DDoS attacks, and third-party failures are common exclusions. Customer configuration errors and unsupported software are often excluded too.
Read whether scheduled maintenance requires notice or has a time limit. A broad maintenance exception can remove much of the uptime promise.
Check every dependency by name. An excluded carrier, DNS host, CDN, registrar, or payment API can cause a full outage.
In that case, no eligible SLA event may exist.
Per-resource wording can turn a company-wide incident into a tiny line-item credit. One failed Northern Virginia zone can break a single-zone app.
The provider may still report the wider region as healthy. That report does not mean your customers could reach the app.
Before signing, mark clauses such as “sole and exclusive remedy,” “at provider discretion,” and “affected service only.” Also flag “as determined by our monitoring.”
These terms do not always erase value. They define the SLA's real limit.
Use a contract checklist before accepting SMB hosting terms. Define downtime as a failed user action, such as storefront loading, login, or payment submission.
Confirm the notice period, maximum duration, and frequency limit for maintenance exclusions. List DNS, CDN, payment, identity, carrier, and backup dependencies.
Identify which dependency failures are excluded. Compare the maximum service credit and liability cap with your outage risk.
A monthly uptime promise is not meaningful compensation when recovery is limited to a narrow resource fee. The claim process can reduce its value even further.
Claim credits before a short deadline voids them
A valid credit claim needs independent evidence, a support case, and a formal request. You must file before the contract deadline.
What evidence must be captured first?
Capture UTC timestamps, monitor alerts, screenshots, failed transaction IDs, app logs, DNS results, and support messages. UTC is a global time standard.
UTC avoids confusion between Pacific, Central, and Eastern time during an escalation. It also makes your evidence easier to match with provider logs.
- Start and end time: Record the first failed customer action and the verified recovery time.
- Affected identifiers: Save the account ID, instance ID, region, availability zone, domain, and ticket number.
- Business impact: List failed checkouts, blocked logins, missed calls, or affected client sites.
- Proof files: Keep raw alerts and logs before retention rules delete them.
How do you beat the claim deadline?
Open a ticket as soon as the outage begins. Do this even when the provider posts an incident.
State the affected service, UTC start time, user impact, and SLA review request. Do not wait for the provider's final incident report.
For a renewal or larger SMB account, request written terms. Ask for automatic credits after confirmed incidents.
Ask for a 30-day or longer claim window. Request accepted external monitors and a named escalation route for priority incidents.
For example: “Provider will apply applicable service credits automatically within one billing cycle after a verified outage.” This avoids requiring a customer claim.
Uptime credits are not the main decision factor for personal projects, development environments, or sites without revenue impact. They matter less for firms with tested multi-region high availability. Credits do not replace backups, cyber insurance, disaster recovery, or a business continuity plan. A credit cannot restore lost data or recover a missed launch window.
Follow a fixed claim sequence. First, save raw alerts, transaction failures, logs, DNS results, and screenshots with UTC timestamps.
Save them before retention settings overwrite the evidence. Second, open a support ticket immediately and record its number.
Record resource IDs, region, and customer impact. Do not rely only on a public status page.
Third, calculate the outage interval after service recovers. Use the SLA definition and compare it with the provider's measured interval.
Fourth, file the formal request before the stated deadline. Attach evidence and cite the relevant SLA section.
Save the provider response and check the correct invoice. An approved claim may be prorated to one service or region.
Fast evidence turns an outage into a claim. The final questions cover the contract details buyers miss most often.
Frequently asked questions
What does a 99.9% uptime SLA mean?
A 99.9% monthly SLA permits about 43.2 minutes of covered downtime in a 30-day month. Its value depends on downtime definitions, exclusions, and credit limits.
The credit may be limited to one service. It may not cover your full business loss.
Are uptime service credits paid in cash?
Most hosting uptime credits are future invoice discounts, not cash payments for lost business revenue. Check for “sole and exclusive remedy” language.
That language often limits recovery to the stated service credit. It can block claims for wider business losses.
Can Azure or AWS deny an SLA credit claim?
Azure or AWS can deny claims for excluded events, late filings, or uncovered service layers. Review exact product terms before filing.
Compute, storage, and databases can have different uptime promises. One vendor brand does not mean one SLA.
Does scheduled maintenance count as downtime?
Scheduled maintenance often does not count as SLA downtime when the contract excludes it. Confirm the required notice and allowed duration.
Check whether emergency maintenance has separate rules. Accepting vague maintenance language can weaken the whole promise.
Is a VPS SLA better than cloud hosting credits?
A VPS SLA is not automatically better because the remedy depends on the contract and your design. Cloud hosting can reduce risk through multi-zone failover.
A single VPS remains a single point of failure. That is still true even with a higher uptime percentage.
What should an SMB monitor for an SLA claim?
An SMB should monitor transactions, uptime, latency, DNS, and errors from at least two external locations. Save UTC timestamps, logs, tickets, and failed transaction records.
Keep records for between 7 and 30 days or longer. Your provider's claim deadline may require longer retention.
The essential points:- A high uptime percentage does not measure your likely payout or real business loss.
- Compare one hour of outage exposure with the precise affected resource's credit cap.
- Read exclusions, maintenance rules, monitoring language, and claim deadlines before choosing a provider.
- Use external transaction monitoring and open an incident ticket when a failure starts.
- For critical workloads, buy resilience through redundancy and failover instead of relying on service credits.
Related sources
These articles can help you explore the topic in more depth:
