SLA (Service Level Agreement)

An SLA is the contractual promise a proxy or scraping API vendor makes about the service it delivers, plus what you get when the promise is broken. Buyers routinely collapse three separate things into the phrase. The service level objective is the number, usually 99.9 percent uptime. The measurement method says whose telemetry counts, at what percentile, over what window, and with what sampling. The remedy says what happens when the number is missed, which in this market is almost always a service credit against a future invoice and only occasionally a termination right for sustained breach. A headline number with no stated measurement method and a credit-only remedy is marketing with a signature block on it.

Four clauses decide whether the agreement has teeth. First, scope: does the SLA cover request success rate at all, or only gateway availability? Most cover the latter, which means the vendor is promising its endpoint answers, not that the answer contains your data. Second, the exclusion list: target-side blocking, CAPTCHA challenges, site layout changes and customer misconfiguration are commonly carved out, and between them they can cover nearly every failure that actually hurts you. Third, the definition of downtime, including the minimum duration before an incident counts and whether partial degradation counts at all. Fourth, the claim process: who must raise it, within how many days, and on whose evidence. A 30-day claim window and a requirement to cite the vendor's own status page is a real constraint, not boilerplate.

Enterprise deals in this market are usually shaped as committed monthly volume at a discounted unit rate with a stated overage rate above it, plus a support response tier and a named contact. The SLA rides on that contract rather than on the self-serve terms, which is why the public pricing page rarely tells you anything useful about it. Vendors including Oxylabs, Bright Data, Zyte and DataForSEO all sell at that tier; the specific terms each offers are negotiated and not published, so treat any number you have not read in your own contract as unconfirmed.

Instrument your own side before you need to argue. Log every request with a timestamp, the target host, the vendor-returned status, your own classification of the body, and end-to-end latency, and retain it for at least the claim window. Vendors adjudicate credits from their dashboard by default, and their dashboard does not see the soft blocks that a 200 response can carry. Your log is the only artefact that lets you substantiate a claim instead of accepting a summary.