If you are putting a proxy network into a production pipeline, someone in procurement or platform engineering will eventually ask what the SLA is. It is the right question, and the answers you get back are usually less informative than they look, because a number like 99.9% means nothing until you know what it is measured against, over what window, and what happens when it is missed.
There is also a specific trap in this category. A proxy SLA promises that the gateway is reachable. It does not promise that the sites you collect from will let your requests through, and those are very different things. Understanding that boundary is most of what you need before signing anything.
What an uptime figure actually means
Three variables sit behind every percentage, and a provider that only gives you the percentage has given you the least useful part.
The first is the measurement window. A 99.9% monthly SLA permits roughly 43 minutes of downtime per month. The same 99.9% measured annually permits about 8 hours 45 minutes, and it allows those hours to be consecutive. Monthly is meaningfully stricter, and a provider quoting an annual figure is quoting a weaker promise in identical language.
The second is the definition of downtime. Is the service down when the gateway refuses connections, or also when it is technically answering but the error rate has spiked, or latency has degraded to the point of uselessness? Many SLAs count only hard unavailability, which means a period where every request returns an error but the endpoint is still accepting connections may not register as downtime at all.
The third is who measures it. If the provider is the sole source of truth and publishes no independent record, the figure is self-reported. A public status page with incident history is what makes it checkable.
The distinction that matters most: gateway uptime is not success rate
This is the part that catches teams out, and it is worth being blunt about.
An uptime SLA covers the provider’s infrastructure: the gateway accepts your connection, authenticates you, and routes your request. That is what they control and that is what they are promising.
What it does not cover is whether the target site accepts the request. If a site blocks the exit address, serves a challenge page, or returns an empty result, that is not downtime. The proxy did its job. Your collection still failed. No proxy provider can promise a success rate against third-party sites, because the sites decide, they change their defences without notice, and the same pool that clears a target on Monday can struggle on Friday. Any provider that does guarantee a success rate on arbitrary targets is promising something outside their control.
So the practical consequence for procurement is that the SLA protects you against the provider being broken, and your own monitoring protects you against everything else. You need both, and conflating them leads to teams that are contractually covered and operationally blind. That is what monitoring your pipeline is for, measuring validated success rate per target and per region rather than assuming the SLA covers it, and it is why detecting blocked or fake content matters: a challenge page returned with a 200 is an SLA-compliant response and a data failure at the same time.
Service credits, and what they are really worth
When an SLA is missed, the standard remedy is a service credit, usually a percentage of the monthly fee scaled to how badly the target was missed, applied to a future invoice.
Be clear-eyed about the size of that. A credit is calculated against what you paid the provider, not against what the outage cost you. If a four-hour gateway outage stalls a pricing feed that drives your own commercial decisions, the credit will be a small fraction of a monthly proxy bill and the business impact is yours. Credits are an accountability mechanism and a signal that the provider takes the commitment seriously; they are not insurance.
Two mechanical details are worth checking. Credits are usually not automatic: many contracts require you to claim within a window, often 30 days, with your own evidence. And credits are typically capped at some percentage of the monthly fee. Both are normal, but you should know them before you need them.
The exclusions to read carefully
The exclusions section is where an SLA is really defined. Standard and reasonable ones include scheduled maintenance announced in advance, force majeure, and failures in networks the provider does not operate. Watch for these:
Scheduled maintenance with no cap or no notice period, which effectively lets the provider exclude any downtime it declares in advance. Exclusions for “customer misconfiguration” that are broad enough to cover ordinary usage. Third-party exclusions written so widely that upstream network problems, which are most of what actually breaks, fall outside the promise. And exclusions for degradation as distinct from unavailability, which is how a slow-but-alive service avoids counting.
Also check whether the SLA covers the components you actually depend on. A proxy business has several: the gateway, the panel and authentication, billing, and any APIs. An SLA that covers the gateway while auth is excluded is not much protection, since you cannot use a reachable gateway you cannot authenticate against.
How to verify a claim before you sign
An SLA is a promise about the future; the checkable things are the present and the past.
Start with the status page. Real-time status and, more importantly, a public incident history tell you how often things break, how quickly they are acknowledged, and whether postmortems are honest. A provider with no public status page is asking you to take uptime on faith. Shifter publishes one at status.shifter.io with the gateway, ISP IPs, the APIs, panel and auth, and billing tracked as separate sub-services, which is the granularity you want since it lets you see which component failed.
Then measure it yourself during evaluation. Run a low-frequency availability check against the gateway from your own infrastructure through a trial period, and you will have an independent record instead of a marketing figure. Combine that with a proper success-rate test on your real targets, as in testing speed, success rate, and location accuracy, and you will know both numbers: whether the service is up, and whether it works for you.
Finally, look at support response times, because in practice they matter more than the credit. When something breaks at 02:00, what determines your recovery is how fast a human answers, not what percentage appears on next month’s invoice.
What Shifter publishes
For reference, the published tiers are: best effort on Starter through Growth, typically 99.5% or better; 99.9% monthly uptime on Business through Pro without a formal credit mechanism; and 99.9% on Enterprise with service credits per the signed contract, calculated against monthly spend and paid as account credit on the next invoice. Support response times are tiered alongside, from best-effort chat on entry plans through to a dedicated channel and a named account manager on Enterprise. The details are in the support and SLA documentation.
The reason for stating that plainly is that tiering is normal across this industry and worth understanding: a formal, credit-backed SLA is generally an enterprise-contract feature, and if your procurement process requires one, that is the conversation to have up front rather than assuming a self-serve plan carries it.
The questions to ask in procurement
Ask for the measurement window and whether it is monthly or annual. Ask for the definition of downtime, specifically whether elevated error rates or degraded latency count. Ask which components the SLA covers, gateway, auth, panel, APIs, and whether they are measured separately. Ask whether credits are automatic or claim-based, what the claim window is, and what the cap is. Ask for the incident history for the last twelve months. Ask what the support response commitment is for a production-down incident, and through which channel. And ask what is explicitly excluded.
A provider comfortable answering all of that in writing is telling you something useful, independent of the number itself.
The bottom line
Treat the percentage as the least informative part of an SLA. The window, the definition of downtime, the covered components, and the exclusions are what determine whether the promise means anything, and service credits are accountability rather than compensation for your losses. Most importantly, remember the boundary: an uptime SLA covers the gateway being available, never whether third-party targets accept your traffic, so you still need your own success-rate monitoring to know if your collection is actually working. Verify with a public incident history and your own measurements during a trial, and weigh support responsiveness at least as heavily as the number itself.
If you are evaluating on that basis, the plan-level choices are covered in choosing the right residential proxy plan, and the provider-level criteria in how to choose a proxy network. The service itself is residential proxies, with tiers and per-GB pricing that scale from self-serve up to contracted Enterprise terms.