A proxy SLA is only as useful as its definitions: what is measured, where, over what window, what is excluded, and what you receive when the target is missed. Many SLAs in this market measure gateway availability, which can read 100% while your requests fail. Negotiate the metric first, then the exclusions, then the credits, and assume that credits will not cover your actual loss. For a vendor that misses repeatedly, the remedy that matters is the right to leave.
What a proxy SLA actually measures
The same phrase, "99.9% uptime", can describe very different commitments. Before comparing percentages, establish which of these a proxy SLA measures.
| Metric | What it tells you | What it hides |
|---|---|---|
| Gateway availability | The endpoint accepted connections and authenticated them | Whether requests reached an exit address or the target |
| Request success rate | The share of requests that completed through the network | How "success" is defined, and whether target-side blocks count as success |
| Per-address availability | A specific static address was reachable and routing | Whether that address is blocked by the sites you care about |
| Replacement time | How quickly a failed or blocked static address is replaced | How often replacement is needed |
| Latency | Time to first byte or full response through the network | Variation by country, target and time of day |
Gateway availability is the easiest for a vendor to measure and the least connected to your outcome. A gateway can accept every connection and still fail to reach an exit address in the country you asked for. It is necessary, not sufficient.
Request success rate is closer to what you care about, but read the definition. A request that returns an HTTP 403 from the target has technically succeeded through the proxy. Some vendors count it as success, some exclude target responses from the calculation entirely, and a few define success only against a set of neutral test endpoints. None of those is your target list.
Per-address metrics apply to static products, ISP and datacenter, where you hold specific addresses. Here the SLA should cover each address you pay for, not an average across all of them.
Measurement point, window and scope
Three details decide whether a stated figure means what it appears to.
Measurement point. Where is the probe? A check from inside the vendor's own network measures the vendor's systems. A check from an external location measures what a customer would see, including the vendor's upstream connectivity. Ask where the probes run and how often.
Measurement window. Monthly windows are standard. The arithmetic is worth doing: 99.9% over a 30-day month allows about 43 minutes of downtime; 99.95% allows about 22; 99.99% about 4. Also ask about granularity. A five-minute check interval that counts a period as available if any check passed will not see a two-minute outage that repeats every hour.
Pool vs fleet. A fleet-wide figure averages across every country and every pool. A country pool that fails completely for a day barely moves a fleet-wide average if it is a small share of traffic, and if that country is the one you use, the SLA told you nothing. Ask for measurement per pool, or at least per product line and major country, so a breach in the part you use is a breach.
Exclusions to read closely
Exclusions are where an SLA becomes narrower than its headline. Some are reasonable; each should be defined.
- Target-side blocks. A vendor cannot guarantee that a third-party site will accept traffic, so excluding blocks by the destination is standard. The question is how a block is distinguished from a network fault. A timeout at the exit is the vendor's problem, whatever the target.
- Customer misconfiguration. Wrong credentials, an unsupported protocol, a request for a country that is not offered. Reasonable, provided the vendor's error responses make the cause identifiable. Troubleshooting proxy 403 and 429 errors shows how to tell the two apart.
- Scheduled maintenance. Reasonable with a cap on total hours per month, a minimum notice period, and a window outside your peak hours. Uncapped maintenance turns any outage into a scheduled one.
- Force majeure. Standard, but it should not include failures of the vendor's own upstream providers, which are its responsibility to manage.
- Excess usage. Some SLAs lapse above a concurrency or rate threshold. If so, the threshold should be stated and above your planned peak.
Credit formulas, caps, and what credits are worth
Service credits are usually calculated as a percentage of the monthly fee for the affected service, in tiers: a set percentage for each step below target, up to a cap. Read four things.
- The base. Is the credit a percentage of the affected product's monthly spend, or of the whole account? Of the affected pool, or the product line?
- The cap. Credits are almost always capped, commonly at a fraction of the monthly fee. A cap means that after a certain point, further failure costs the vendor nothing more.
- Claim or automatic. Many SLAs require you to claim within a set number of days, with evidence. Automatic credits are better, because a credit you have to claim is a credit you will often forget.
- Form. Credits are nearly always applied to future invoices or a prepaid balance, not refunded. They are worth nothing if you leave.
Now compare a credit with the cost of an outage. Suppose a team spends 20,000 a month on residential traffic and the pool it depends on is unusable for a full business day. At a typical tiered formula the credit might be a tenth of the month's fee for that product. The cost to the business is a day of missing pricing data, delayed reports, engineering time spent diagnosing, and whatever decisions were made on stale information. That cost usually bears no relation to the monthly fee.
Credits are not compensation. They are a price signal that makes the vendor feel a breach, and they are evidence that a breach occurred. Your actual protection comes from a second source you can fail over to, which proxy redundancy covers, and from the right to terminate.
Replacement SLAs for static addresses
For ISP and datacenter addresses, an availability figure is less useful than a replacement commitment. A static address can be up and routing and still be useless because a target has blocked it. The terms to negotiate:
- Replacement time from your report of a failed or blocked address to a working replacement in the same country and, where relevant, the same subnet diversity.
- Replacement allowance. Whether replacements are unlimited or capped per month, and whether any carry a fee.
- Credit for the gap. A pro-rata credit for time the address was below standard, not only for time it was down.
- Diversity. Whether replacements come from different ranges, so a range-level block does not follow you.
Dedicated vs shared proxies and static residential proxies explain why block behavior differs across these products.
Support response times and termination for chronic breach
Support response belongs in the SLA, not a sales email. Ask for first response times by severity, the hours those apply, and what counts as severity one. For production traffic, severity one should mean a complete loss of service on a product you use, with a response measured in minutes to an engineer, not a ticket acknowledgement. A named technical contact is worth more than a faster auto-reply.
Termination for chronic breach is the clause that gives the rest of the SLA teeth. Negotiate the right to terminate without penalty, with a refund of unused prepaid balance, if the SLA is missed in, for example, two consecutive months or three months in any rolling twelve. Without that clause, a vendor can miss every month and pay capped credits that you can only spend with it.
Verifying the SLA with your own monitoring
A proxy SLA measured only by the vendor is a report the vendor writes about itself. Run your own measurement, from your own infrastructure, against your own targets.
- Probe the gateway and a neutral endpoint on a fixed interval, per product line and per country you use.
- Record success rate, error class and latency for production traffic, broken down by pool.
- Keep the data at least as long as the SLA claim window, with timestamps in UTC.
- Alert on the same thresholds the SLA uses, so you know about a breach before the invoice arrives.
Proxy monitoring covers how to build this, and the same data is what you would use in a provider benchmark or an RFP pilot.
A proxy SLA negotiation checklist
- The metric is defined: availability, success rate, or per-address, and how success is defined
- The measurement point and check interval are stated
- Measurement is per pool or per country, not only fleet-wide
- Exclusions are listed, and scheduled maintenance is capped with notice
- Credit base, tiers and cap are stated; credits apply automatically
- Static addresses carry a replacement time and allowance
- Support response times by severity are in the contract
- Termination without penalty for repeated breach, with prepaid balance refunded
- The vendor's measurements can be reconciled with ours on request
The same questions appear as scored items in the proxy provider RFP template.
How ProxyForge publishes its SLA terms
ProxyForge publishes SLA terms per proxy line rather than one figure for everything: availability, the quality target, support, and how service credits are calculated. Each product page states them, so you can read the terms before you buy rather than after you negotiate. Start from the products overview, or go directly to the residential or ISP product page.
Every account has a named engineer for support. If you are comparing our terms with your incumbent's, the migration process lets you run both in parallel and measure each proxy SLA against your own monitoring before you shift traffic.