---
title: "Success rate"
url: https://proxy.wiki/glossary/success-rate/
type: Glossary Term
author: "proxy.wiki editorial"
published: 2026-08-19
updated: 2026-08-29
site: proxy.wiki
topics: ["Web scraping"]
license: CC BY 4.0 — quote freely with attribution to https://proxy.wiki/
---

# Success rate

> The share of requests that return a usable response. Meaningless without a sample size and a named target.

**Success rate is the proportion of requests that produce the response you wanted.** It is the headline metric in proxy marketing and the one most often quoted without the context needed to interpret it.

## What a rate needs to mean anything

- **A sample size.** “98%” from 100 requests and from 100,000 are very different claims.

- **A definition of success.** A 200 response containing a block page is not a success, though naive measurement counts it as one.

- **A named target.** Rates against an echo service and against a heavily defended retailer are not comparable.

- **A date.** Pools and defences both change continuously.

## The most common measurement error

Counting HTTP status alone. Many [anti-bot systems](/glossary/anti-bot-system/) return 200 with a challenge page or an empty result set, because doing so wastes the scraper’s time. Validate that the response actually contains what you asked for, not merely that the request completed.

## Reading provider claims

A rate published without sample size, target and date is marketing. Treat it as a claim about the vendor’s confidence, not as a measurement.

## What a rate must state to be meaningful

A percentage on its own is not a measurement. Five facts turn it into one, and a claim missing any of them cannot be compared with another claim.

| Fact | Why it changes the number |
| --- | --- |
| Sample size | A rate over a handful of requests is noise |
| Target | Sites differ enormously in how hard they are |
| Date | Defences change, so results expire |
| Definition of success | A 200 with a challenge page is not a success |
| [Concurrency](/glossary/concurrency/) | Rates fall as parallelism rises |

## The error that inflates every number

Counting HTTP 200 as success is the most common measurement mistake, and it always flatters the result. A challenge page, a consent wall and an empty result set all return 200. So does a page served to a suspected bot with the data removed.

Validate the content instead. Assert that a field you actually need is present and plausible, and count anything else as a failure however the status code reads. A rate measured this way is lower and useful; a rate measured on status codes is higher and meaningless.

## Why we publish no provider rates here

We do not print a success rate unless we ran the test and can state all five facts above. A number without them tells a reader nothing they can act on, and repeating a vendor’s figure as though it were a measurement would be worse than printing nothing.

## Frequently asked questions

### Why do provider success rates differ so much from what I measure?

Usually because of the target and the definition. A rate measured against undefended sites, counting any 200 as success, is much higher than a rate measured against a hard target with content validation. Ask which target, which date and which definition.

### How should I define success in my own monitoring?

By content, not by status. Assert that the field you need is present and plausible. A challenge page, a consent wall and an empty result all return 200, so a status-based rate systematically overstates how well the job is working.

### How large a sample do I need?

Large enough that a handful of failures does not move the figure noticeably, and spread across time rather than taken in one burst. A single burst measures one moment on one target, and defences vary through the day.

## Sources

1. [RFC 9110: HTTP Semantics, what a 200 response actually asserts](https://www.rfc-editor.org/rfc/rfc9110.html)