cloud phone SLA expectations: what to demand in 2026
cloud phone SLA expectations: what to demand in 2026
cloud phone SLA expectations in 2026 should be specific, measurable, and contractually binding. anything else is marketing. teams that sign on the standard SLA without reading it almost always discover later that the 99.9% uptime number means something different than they thought, or that exclusion clauses make breaches almost impossible to claim. this guide covers what numbers to demand, what language to insist on, and where vendors typically push back.
if you are still in the buying flow, the vendor RFP template covers SLA at a higher level. this article is the deep dive on a single critical section.
the four numbers that matter
every cloud phone SLA reduces to four numbers.
- uptime percentage (e.g. 99.9%)
- measurement window (monthly, quarterly, annual)
- measurement scope (per-device, per-region, account-wide)
- credit schedule (X% of monthly fees per Y minutes of breach)
a vendor that quotes “99.9% uptime” without specifying the other three has not given you an SLA. they have given you a marketing line.
what uptime percentages actually mean
| uptime | downtime per year | downtime per month |
|---|---|---|
| 99.0% | 3.65 days | 7.3 hours |
| 99.5% | 1.83 days | 3.65 hours |
| 99.9% | 8.76 hours | 43.8 minutes |
| 99.95% | 4.38 hours | 21.9 minutes |
| 99.99% | 52.6 minutes | 4.38 minutes |
99.9% sounds great until you realize it allows almost an hour of downtime per month, which can cost a team running CI dependencies tens of thousands of dollars in delayed builds. 99.95% is the floor for production-critical use cases. 99.99% is achievable but expensive.
what to demand by use case
| use case | minimum uptime | minimum measurement |
|---|---|---|
| ad-hoc QA testing | 99.0% | monthly, account-wide |
| automated CI test runs | 99.5% | monthly, regional |
| multi-account customer farms | 99.9% | monthly, per-region |
| production support flow (e.g. customer 2FA testing) | 99.95% | monthly, per-region |
| safety-critical workflows | 99.99% | monthly, per-device |
push for the lowest measurement scope your use case justifies. account-wide hides regional outages. per-device is gold standard but rare on standard SLAs.
response time SLA, not just uptime
uptime tells you how often the platform works. response time tells you how fast support shows up when it does not.
ask for explicit response times by severity, in writing.
| severity | recommended response | typical 2026 vendor offer |
|---|---|---|
| P1 (production down) | 15 minutes | 1 hour |
| P2 (major degradation) | 1 hour | 4 hours |
| P3 (minor issue) | 4 business hours | next business day |
| P4 (question / how-to) | 1 business day | 3 business days |
if the vendor’s standard SLA is 1 hour for P1 and you need 15 minutes, that is a tier upgrade or a custom MSA addendum. ask for the price up-front.
the credit schedule
credits are the financial teeth of the SLA. without them, the uptime number is a hope, not a promise.
a fair 2026 credit schedule looks like this.
| breach severity | credit |
|---|---|
| 99.9% missed by < 0.5% | 10% of monthly fees |
| missed by 0.5-1.0% | 25% |
| missed by > 1.0% | 50% |
| missed by > 2.0% | 100% |
credits typically cap at 50-100% of the monthly fee. a vendor offering “up to 25% credit” is offering very little. push back to at least 50% maximum, and ask for the schedule in writing.
the exclusions that hollow out an SLA
four exclusions are standard. four others are predatory. learn the difference.
standard, accept
- scheduled maintenance windows announced 14+ days in advance
- force majeure (natural disasters, war, civil unrest)
- customer-caused issues (bad APK, mis-configured integration, expired token)
- third-party network outages outside vendor’s control
predatory, push back
- “scheduled maintenance” with vague definition (could be every Friday)
- “performance degradation not constituting downtime” (effectively excludes slowness)
- “during beta features even on GA tier” (excludes anything new)
- “above stated rate limits” (when those rate limits are deliberately low)
if the vendor refuses to remove the predatory exclusions, factor it in. a 99.9% SLA with broad exclusions is functionally a 98%.
measurement methodology
an SLA is only enforceable if both parties agree on how to measure. ask the vendor to specify:
- probe locations: where the uptime probes run from
- probe frequency: every minute, every 5 minutes
- probe operations: simple ping, full lock-and-unlock cycle, ADB connect
- public dashboard: link to the live uptime data
a vendor that probes from inside their own datacenter every 5 minutes and only measures pings is reporting an inflated number. a vendor that probes from third-party regions every minute with real lock-unlock cycles is reporting reality.
if their probes do not match real customer flows, build your own. the webhook automation and API basics articles give you everything needed for a synthetic monitor.
claiming credits
most vendors require you to claim credits explicitly. they do not auto-apply.
- the SLA usually has a 30-60 day window to file the claim
- you will need timestamps, error logs, ticket references
- credits typically apply to the next month’s invoice, not as a refund
set a calendar reminder on the first business day of every month to scan the prior month’s incidents and file claims. this is unsexy work that recovers real money over time. teams that do it recoup an average 3-7% of annual fees.
negotiation tips
three things vendors will usually accept if you push.
- raising the credit max from 25-50% to 50-100% of monthly fees
- removing one or two exclusions (especially the vague “performance degradation” one)
- adding a quarterly SLA review meeting
three things they will usually push back hard on.
- per-device measurement scope
- 99.99% uptime on the standard tier
- response times below 15 minutes for P1
a fair compromise in 2026: 99.9% per-region uptime, 30-minute P1 response, 50% credit cap, no vague exclusions. if you cannot get there, the TCO worksheet needs to factor in the risk.
sample SLA addendum to attach to your MSA
Service Level Agreement Addendum
1. Availability: Provider commits to 99.9% monthly uptime measured per region.
2. Measurement: third-party probes from at least 3 distinct regions, every 60s,
running a full lock and unlock cycle on a representative device.
3. Public Dashboard: Provider maintains a public status page with at least 90
days of historical incident data, updated within 15 minutes of any incident.
4. Response Times: P1 30 minutes 24x7, P2 2 hours 24x7, P3 4 business hours,
P4 1 business day.
5. Credits: 10% / 25% / 50% / 100% of monthly fees per breach severity tiers
defined in Schedule A. Customer claim window 60 days. Credits applied to
next invoice.
6. Exclusions: scheduled maintenance with 14 days notice; force majeure;
customer-caused issues. No other exclusions apply.
attach as Exhibit B to the MSA. push this exact language. negotiate from there.
frequently asked questions
what if the vendor’s standard SLA is way below 99.9%?
ask for the enterprise SLA add-on price. if it is reasonable (5-15% premium), buy it. if it is 30-50% extra, factor that into the TCO comparison and re-evaluate the vendor.
can I demand a custom SLA?
yes for enterprise contracts. mid-market vendors typically resist. small vendors will negotiate but their actual operational ability to hit a tight SLA may be limited.
how do I handle SLA breaches that affect business but no one filed a claim?
build the claim process into your incident response. every P1 should generate a SLA-impact entry that flows to your finance team for monthly review.
are credits the only remedy?
usually yes. some MSAs add a termination right after multiple consecutive breaches. push for a “3 consecutive months at >0.5% breach allows termination without penalty” clause if you can.
what about iOS or other platforms in the same SLA?
cloud phone SLAs typically only cover Android. if you have iOS via the same vendor, get a separate SLA addendum or accept that iOS is unsupported under the standard agreement.
ready to size up your SLA expectations? start a cloudf.one trial, check the published SLA against the demands above, and use it as your benchmark for other vendors.