Scraping Vendor SLAs Are Converging on 99.5/99.9/99.99
Scraping vendor SLAs in 2026 cluster into three bands: self-serve at 99.5% (3.6h/month downtime budget), mid-market at 99.9% (43min/month), enterprise at 99.99% (4.3min/month). Structure mirrors AWS rather than SaaS norms. Enterprise credit-back terms remain customer-by-customer.
The Service Level Agreement landscape across scraping infrastructure vendors converged through 2024-2026 on three discrete bands: 99.5% for self-serve tiers, 99.9% for mid-market, 99.99% for enterprise. The structure is now visible across Bright Data, Apify, Zyte, Browserbase, Firecrawl, and the residential-proxy reseller tier. The pattern mirrors AWS and infrastructure-as-a-service norms rather than the SaaS-typical 99.5% blanket guarantee.
The convergence matters because SLA terms now drive enterprise buyer-side procurement decisions in a segment where they were historically irrelevant. A 99.99% guarantee — 4.3 minutes of monthly downtime — is the threshold below which most enterprise procurement processes will not approve a scraping vendor as production-critical infrastructure. The vendors that compete for enterprise buyers have aligned around this number.
The three-band structure
The SLA-tier mapping across observed vendor documentation as of mid-2026:
| Tier | Guaranteed uptime | Monthly downtime budget | Typical credit-back |
|---|---|---|---|
| Self-serve | 99.5% | 10% credit on missed month | |
| Mid-market | 99.9% | 25% credit on missed month | |
| Enterprise | 99.99% | Custom, often 50-100% credit |
Most vendors offer multiple tiers. Bright Data’s self-serve residential proxy plans guarantee 99.5%; its enterprise contracts guarantee 99.99%. Apify’s platform-level SLA on its free and starter tiers is 99.5%; the team and enterprise plans escalate to 99.9% and 99.99%. Browserbase, Firecrawl, ZenRows, Scrapfly all show similar tier structures.
The exceptions are informative. Smaller scrapers without enterprise customer bases (ParseHub, Webscraper.io, some of the residential-proxy resellers) do not publish SLA terms at all. The absence is a signal — they cannot commit to enterprise-grade uptime because their infrastructure does not support it.
Why the bands stabilized here
Three forces drove the convergence on these specific numbers.
Downstream enterprise expectations. Buyers in regulated industries (financial services, pharmaceuticals, large-enterprise procurement) require vendors to commit to 99.9% or 99.99% to be considered production-grade. Vendors that want to sell into these buyers had to match the convention. The convention itself came from AWS and the broader IaaS market, which set the 99.99% bar for infrastructure-tier services in the 2010s.
Insurance and risk-management math. A vendor that commits to 99.99% needs operational infrastructure capable of delivering that — multi-region redundancy, automated failover, 24/7 on-call rotation. The cost of building this is meaningful. Vendors with smaller customer bases cannot amortize the cost; vendors with enterprise customer bases have to.
Competitive signaling. Publishing SLA terms is partly a marketing statement. A 99.99% guarantee tells enterprise buyers “we are at infrastructure-grade reliability”; a 99.5% guarantee tells the same buyer “we are not, look elsewhere.” The signal value of the higher number drove vendors with enterprise ambition to commit even when their actual operations are less reliable than the published number.
The credit-back complication
The published SLA tier numbers tell only part of the story. What the buyer actually gets when the vendor misses the SLA varies meaningfully and is where the contract terms matter.
Self-serve credit-back is usually automatic but small. A vendor that misses 99.5% gives the buyer a 10% credit on the affected month, typically applied to the next invoice. The credit caps at the full monthly fee and does not include consequential damages from the buyer’s downstream business impact.
Mid-market credit-back is larger but requires customer notification. A vendor that misses 99.9% may give 25% credit, but the customer typically has to file a notification within a specified window (usually 30 days) and document the impact. Vendors that quietly miss SLA without proactive customer notification often end up not paying out.
Enterprise credit-back is custom and consequential-damages-exclusive. Enterprise contracts may credit 50-100% of the affected month, but almost always exclude consequential damages (the buyer cannot recover their downstream business losses, only the direct vendor fee). The customer’s actual exposure on a critical outage is meaningfully larger than the credit-back amount.
The buyer-facing reality is that SLA credits compensate for vendor under-performance but do not insure against the buyer’s actual business losses. For mission-critical workloads, the buyer needs to architect their own redundancy (multi-vendor, fallback infrastructure) rather than rely on a single vendor’s SLA.
What’s missing from current SLAs
Three meaningful gaps in current scraping-vendor SLA terms remain customer-by-customer territory.
Success-rate guarantees. Scraping success rate (what % of requests return usable data) is distinct from uptime (whether the service is responsive at all). A vendor at 99.99% uptime with a 40% success rate against the target site is delivering 39.6% effective service. Most SLAs do not commit to success rate. Some enterprise contracts include success-rate targets as bespoke terms.
Geographic-tier guarantees. A vendor with strong US residential proxy coverage but weak APAC coverage may meet aggregate SLA while failing entirely in specific geographies. Enterprise buyers with global operations require geographic-tier SLA commitments that are not in the standard tier structure.
Anti-bot bypass guarantees. When the target site upgrades its anti-bot defenses, scraper effectiveness can drop sharply. Most SLAs treat this as “out of scope” — the vendor is not responsible for the target site changing. Some enterprise contracts now include adaptation-window guarantees (the vendor will restore bypass capability within X days of a target-site defense change), but this remains rare.
What it means for buyers
For Apify Store publishers and other scraping-vendor buyers, the SLA-tier convergence sharpens the procurement decision.
Self-serve workloads should expect 99.5% and price the risk. A buyer using a self-serve tier plans for ~3.6 hours of monthly downtime as the baseline. Workloads that cannot tolerate this either upgrade to a higher tier or build their own redundancy.
Mid-market workloads land at 99.9%. A buyer with steady commercial volume on a single vendor should expect to be at the 99.9% tier and price the contract accordingly. Most published mid-market pricing assumes this tier; downgrading buys a few cents per request but doubles the downtime budget.
Enterprise workloads need 99.99% plus bespoke contract terms. A buyer running scraping infrastructure as part of a regulated or mission-critical workflow needs the enterprise tier and needs to negotiate the credit-back, geographic, and success-rate terms beyond the published SLA.
The longer-term implication for the scraping vendor landscape is that the SLA tier becomes a competitive moat. Vendors that achieve 99.99% sustained uptime over multiple years can credibly compete for enterprise contracts; vendors that cannot consistently hit 99.9% are structurally excluded from the high-margin tier. The vendor productivity ranking and the SLA tier are correlated — high-productivity vendors are typically also high-SLA-tier vendors, because both reflect the operational maturity that enterprise customers require.
Sources
- Public SLA documentation across 20+ scraping vendors (Bright Data, Apify, Zyte, Browserbase, Firecrawl, ZenRows, Scrapfly, ScrapingBee, others)
- AWS Service Level Agreements — reference baseline
- Signal Census: Scraping Vendor ARR-per-Employee — vendor productivity context
- Signal Census: Pricing Fragmentation 47 Models