Service Level Agreements (SLA)

A Service Level Agreement, or SLA, defines the level of service a provider commits to deliver, how it is measured, and what the customer receives if the commitment is missed. For a proxy service, it may cover connection availability, request processing, support response times, and compensation for outages.

SLAs are part of provider policies. In the second half of 2026, the same promise of “99.9% uptime” can describe substantially different arrangements in the proxy market: from availability of a shared gateway to commitments for a particular service under a business contract. Buyers need to understand what the percentage covers and which events qualify as a breach.

The task failed, but the SLA was met

Imagine a company collecting competitors’ prices each morning. Its proxies stop working during the half-hour window when the collection runs. The job is missed, fresh data never reaches the system, and decisions have to rely on yesterday’s prices.

A monthly 99.9% availability SLA could still be met. In a 30-day month, that percentage allows up to 43 minutes and 12 seconds of counted downtime. One half-hour outage stays within the limit, even though its timing was critical to this customer.

Another customer can connect to the proxy, but the store they need returns a block page. If the agreement covers only the availability of the proxy infrastructure, the store’s refusal may not qualify for compensation.

These examples show why an SLA needs to be read in relation to the customer’s task. Its value depends on the scope of the commitment, the calculation method, and the consequences of a breach.

Published terms and business contracts

A provider may publish a standard SLA that applies to specific products or plans. Those terms can form part of the service contract. Being publicly available does not, by itself, make an SLA an optional advertising promise.

A percentage on a homepage, however, does not describe a complete contractual commitment. It could be an operating target, a historical monitoring result, or a characteristic of the infrastructure. The number alone does not explain which failures count or whether compensation is available.

Best effort describes an undertaking to make efforts within the stated terms. The phrase alone establishes neither an availability percentage nor a fixed payment. The meaning of the promise comes from the documents, including the general service terms and the order for the particular product.

A business agreement can separately define locations, performance, support, exclusions, and remedies. But the label Enterprise does not automatically mean financial penalties for every minute of downtime. An expensive contract may still offer only credits toward future service.

Buyers also need to know which products are covered, whether trial access qualifies, which document takes precedence, and how the provider can change the terms. An individual order may specify terms that differ from the public SLA page.

What a provider can commit to deliver

A proxy service has several distinct characteristics. An accessible authentication server, a working exit IP, and a successfully loaded page are three different results.

A gateway might accept requests while exit nodes in the country a customer needs are unavailable. If the measurement covers only the gateway or the network as a whole, a problem in one location may not reduce contractual availability.

A “live IP” and a “clean IP” also describe different things. The first can carry traffic. The second is an assessment whose meaning depends on a reputation database, a target website, and the seller’s promises. Network availability and freedom from blocks need separate definitions.

How much downtime the percentages allow

In a simple calculation, availability is the share of time during which the service is considered operational:

Availability = (1 − counted downtime / measured period) × 100%.

For a month of exactly 30 days, with no excluded periods, the thresholds are:

These are mathematical thresholds, rather than scheduled allowances for maintenance. The actual agreement may use a calendar month of a different length, a billing cycle, or a request-based calculation.

Brief interruptions may not count

Some published SLAs define downtime as total unavailability lasting at least five consecutive minutes. Under that definition, an isolated three-minute interruption may be excluded.

For the customer, repeated brief interruptions can mean lost sessions and restarted jobs. They may remain invisible to the contractual measurement. Partial degradation is not always treated as a complete outage either.

Averaging across a package can hide failures of essential IPs

Consider a hypothetical package of 1,000 addresses. Twenty IPs are unavailable for 12 hours, while the rest work throughout a 30-day month.

Each affected IP has approximately 98.33% availability. Adding the working time of all addresses and averaging across the package produces approximately 99.967%. The package clears a 99.9% threshold even though work on twenty essential addresses stopped for half a day.

The measurement unit therefore matters: an individual IP, a package, a location, a gateway, or the entire network. These numbers illustrate averaging; a particular contract may use a different method.

How the proxy type changes the commitment

With datacenter proxies, the provider usually has greater control over servers and address allocation. Reliability still depends on routing, hosting facilities, and upstream networks. The product name itself does not establish a 99.9% SLA.

For static datacenter and ISP proxies, the fate of the assigned address is particularly important. If it fails, a quick replacement can restore network access. But a customer who needs the original IP for a long-running session receives a different outcome. Replacement time and a commitment to retain the address are separate terms.

In a residential pool built from consumer devices, individual nodes can disconnect for reasons outside the proxy service’s control. The provider can maintain the pool and find replacements, but a large node count does not guarantee that a particular IP remains continuously available. A limited supply in an uncommon location further restricts the choice.

Mobile proxies also differ. A distributed network of consumer devices and a dedicated modem in a physical farm give the operator different degrees of control. A dedicated modem allows different arrangements for restarts and backup capacity, but it remains subject to carrier outages, SIM plan restrictions, and possible changes to the public IP.

Automatic failover can restore connectivity while breaking the current session or changing the exit address. Service availability, session continuity, and address persistence therefore deserve separate wording when a customer’s work depends on them.

Website access and request success

An ordinary proxy forwards traffic, while the target website decides how to respond. It may limit request frequency, require a challenge, or reject an address. If other sites still work through the proxy, a network availability commitment may remain satisfied.

Suppose a store blocks the subnet in use. For a customer collecting data only from that store, the package has effectively lost its value. Whether compensation is due depends on whether the provider promised access to that site or simply a functioning proxy network. The size of the customer’s inconvenience does not, by itself, expand the commitment.

A website unblocker or Scraping API may sell a broader result: a processed request, a retrieved page, or extracted data. Supported sites, request settings, challenge detection, and the definition of a usable response then become important. Charging only for successful requests does not establish a minimum success rate either. Billing rules and service quality commitments address different questions.

“98% successful requests” needs a denominator. Does it count first attempts, all attempts including retries, or completed tasks? Is a CAPTCHA response treated as success? Are requests outside the product’s published limits excluded?

If 2,000 out of 10,000 attempts fail, the observed attempt success rate is 80%. That is a concrete test result. Calling it an SLA breach requires matching the test conditions and causes of failure to the provider’s obligations. There is no universal industry threshold suitable for every website and product.

Retries also change the picture. A task may eventually succeed after several failures while taking longer and consuming more billable traffic. A high final success rate does not reveal the cost or speed of obtaining the result.

Speed: average latency does not describe every request

Latency depends on several stages: the customer’s connection to the proxy, the proxy’s connection to the website, and processing at the website itself. Geography, response size, and simultaneous connection count all affect the result.

A promise of a “500 ms response” therefore needs measurement conditions. It might refer to connecting to the gateway, receiving the first response byte, or loading the complete page. These are different events.

An average can look reassuring despite troublesome delays. In a hypothetical sample of 1,000 requests, 990 finish in 0.2 seconds and ten take 30 seconds. The average remains below half a second, although one request in every hundred takes half a minute.

For workloads sensitive to these delays, an agreement can use percentiles: for example, the time within which 95% or 99% of requests finish. Load and the permitted error rate need their own definitions. One fast test connection does not show how the service will behave under a thousand simultaneous requests.

Support: response, restoration, and a permanent fix

“We respond within 15 minutes” may promise only the start of a conversation. It does not say when the right specialist will take over or when the proxies will work again.

An incident can involve acknowledgment, specialist assignment, temporary restoration, and a permanent fix. Different deadlines may apply to those stages. Some may be operating targets with no separate credit for a missed deadline.

The support schedule matters as well. Two business hours can take much longer than two elapsed hours if a request arrives on Friday evening and support operates on weekdays. Around-the-clock coverage may apply only to critical incidents or a more expensive support package.

The provider may also determine severity. A network-wide outage and one customer’s loss of access to one website may receive different priorities, even if both stop that customer’s business. Escalation arrangements and a way to challenge the assigned priority help explain what happens after the first reply.

Which periods and causes are excluded

Planned maintenance is often treated separately. Published agreements include arrangements such as eight hours of maintenance per month with seven days’ notice. This is one documented approach, rather than a market-wide allowance.

Those hours can still mean unavailability for the customer. Depending on the contract’s formula, they may be excluded from downtime or from the measured period. A high availability percentage can therefore coexist with substantial permitted interruptions. Emergency maintenance may have separate notification rules.

Other common exclusions concern customer equipment and settings, invalid authentication, exhausted account funds, excessive load, and suspension for a policy breach. An unsuccessful request in these circumstances does not necessarily count as a provider outage.

External dependencies deserve particular attention. A proxy service may rent servers, connectivity, and addresses from other companies. A contract may exclude certain events outside its control, but the involvement of a third-party data center does not by itself settle responsibility. The agreed service boundary matters.

Broad exclusions can narrow the commitment considerably. An SLA covering only an internal gateway while excluding location-specific failures gives a buyer different protection from a commitment covering particular exit IPs.

What the customer receives after a breach

Public proxy SLAs frequently use service credits: an amount toward future service, an account balance adjustment, or another agreed remedy. Eligibility for a credit does not automatically mean a refund to the customer’s card.

The amount may depend on an availability band, with larger credits for lower uptime. Other arrangements award credit for each full hour beyond the allowed downtime. A maximum cap or a minimum qualifying amount may also apply.

Consider a hypothetical agreement with a 99.9% target and a 5% credit for a moderate availability shortfall. Two hours of complete, counted downtime over 30 days produce approximately 99.722% availability. With an eligible charge of $1,000, the credit is $50, even if the customer’s missed work cost much more.

The eligible charge can make a substantial difference. Suppose a customer spent $10,000 that month: $200 on the plan and $9,800 on additional traffic. If the agreement applies a hypothetical 10% credit only to the plan fee, the result is $20. Applying it to the entire bill would produce $1,000. This example illustrates the effect of excluding additional purchases; it does not describe a particular company’s plan.

Some agreements use only the charges for affected proxies. Others set a monetary ceiling, limiting a percentage of the monthly invoice to a fixed amount. A credit percentage reveals little about the eventual amount without the eligible charge and cap.

Payment arrangements vary. Some providers allow a credit to the original payment method at their discretion. A negotiated agreement may provide other remedies. Saying that providers never return money for downtime is too categorical.

An ordinary SLA credit, however, is not business insurance. Contracts may limit compensation for lost profits and indirect losses, and may define the credit as the sole contractual remedy for the specified failure. Applicable mandatory customer rights are separate from that arrangement.

Why compensation may not arrive automatically

A recorded incident and an awarded credit are separate events. Published terms include claim deadlines of 14 calendar days after an incident or 30 days after the end of the affected month. Those are different windows; waiting for the next invoice may leave a customer too late.

A review generally needs the outage times, affected resources, and technical evidence that can be compared with the provider’s monitoring. Passwords, tokens, and confidential request content are unnecessary for that purpose and should be removed from diagnostic material.

The agreement may give precedence to the provider’s internal measurements. A public status page helps explain a broad outage, but the absence of a notice does not establish that a particular customer’s IPs were working. Local problems and system-wide incidents may be recorded differently.

Repeated breaches deserve separate attention. Several small credits in succession may not solve the problem of an unreliable service. Negotiated terms can address recurring failures separately, including an agreed right to end service.

Measuring the service the customer actually uses

An open-port check or an ordinary ping tests only part of the path. To assess proxy operation, monitoring needs to pass through real authentication, an exit address, and a request to a destination. An accessible account dashboard cannot substitute for that test.

Two checks serve different purposes: a request to a controlled test destination and a request to the website the customer needs. The first helps reveal a general path failure; the second measures the result for the actual task. Using one public website as the sole reference can introduce that site’s own restrictions and distort the findings.

HTTP status codes also need context. A 502 or 504 can originate at different points along the path; the number alone does not identify who caused it. A 200 response does not establish that the expected data arrived. A useful check considers response origin and content. Cloudflare Challenge Pages, for example, can be identified by the cf-mitigated: challenge header.

Tools such as cURL measure stages of a request, but their output is easy to misinterpret. time_connect measures elapsed time from the start until a connection to the remote host or proxy is established. time_starttransfer measures elapsed time until the first response byte. Subtracting them includes subsequent communication stages and waiting for the website; it does not isolate the proxy’s own processing delay.

Comparable measurements record location, destination, timeouts, response size, concurrency, and retry rules. These conditions explain why a single test and a large collection job can show different performance from the same service.

Reputation checks answer another question. A high risk assessment in one database is neither technical unavailability nor proof that an ordinary SLA was breached. It becomes a contractual criterion when the parties specify the source, threshold, and measurement method. An IP has no universal certificate of “cleanliness” accepted by every website.

What an SLA contributes

A well-defined SLA connects the provider’s promises to the parts of the service that the customer’s work depends on. One buyer needs assigned IPs and a restoration deadline; another needs a particular location; a third needs successful data retrieval and responsive support.

An expensive plan does not by itself ensure those commitments are met, and a low price does not prove their absence. The terms, measurements, and handling of actual incidents matter. Backup capacity and automatic failover help keep a service available, but need to be assessed by what the customer receives after a switch.

If a half-hour interruption can derail a critical job, a fulfilled 99.9% SLA still leaves that risk. Additional backup capacity and the ability to continue through another route address continuity, while the SLA defines obligations and compensation for the failures it covers.