Web Data SLAs Explained: What Freshness, Coverage and Quality Guarantees to Demand From a Data Vendor

The SLA you'll be offered

Here is a lightly edited version of an SLA we were shown by a prospect last quarter. Their incumbent vendor had sent it as proof of reliability. The prospect's data team had just spent eleven days chasing a pricing anomaly that turned out to be a currency field that had silently switched from GBP to EUR on one source.

This is not an unusual document. Public SLAs from web scraping API providers tend to look the same: one published scraping-API SLA commits to a 99% monthly uptime target, allocates credits "based on the actual duration of service downtime" with no stated bands, requires a claim "within a specific timeframe" it does not specify, excludes third-party website restrictions, and says nothing at all about data accuracy or freshness. DataHen's guide to enterprise scraping SLAs describes the pattern from the vendor side: most agreements guarantee delivery volume, carve out maintenance, third-party failures and source-site blocking, and leave the client to detect breaches and file for credits.

None of this is malicious. Uptime is what infrastructure teams know how to measure, and vendors write SLAs for the things they can measure. The problem is that the thing you need measured is different.

Three words that make SLAs readable

The site reliability discipline that grew up inside Google sorted this out years ago, and borrowing its vocabulary makes every SLA conversation shorter. The SRE definitions, from Google's SRE book:

• An SLI (indicator) is the measurement itself. Good events divided by total events, over a window. Share of expected records delivered per source per run.
• An SLO (objective) is the target the provider holds itself to internally. 98% coverage over 30 days.
• An SLA (agreement) is the external contract that attaches consequences to missing a target. 97% coverage, or a credit. The SLA threshold is normally looser than the internal SLO, so the provider's alarms fire before yours would.

Two habits follow from this. First, for every percentage in a vendor's SLA, ask for the SLI: measured against what denominator, over what window, by whom. Second, ask what their internal SLO is. A vendor whose SLO and SLA are the same number has no margin, which means you will be the one who finds out when they miss.

What 99% means at your volume

SRE also gives us the error budget: one minus the objective, expressed in whatever unit hurts. For uptime that is minutes a month. 99.9% is about 43 minutes of downtime per month; 99% is about 7.2 hours. For data, the unit that hurts is wrong rows.

This is the exercise to do before any negotiation: take your actual daily volume, apply the vendor's proposed quality number, and look at the row count. Then ask whether your product can absorb that many wrong values a day, and what each one costs when a customer finds it first. For a pricing product, a wrong price is a support ticket at best and a refund at worst. For a model training pipeline, it may be invisible and permanent.

The right target is the one your product can tolerate, not the one with the most nines. Each additional nine is dramatically more expensive to deliver, because catching the last 0.1% means checks that catch things no automated rule finds. There is a fuller account of those checks in why web scrapers break and how to catch them in hours.

The clauses, one by one

What follows is the structure of a web data SLA that actually protects the buyer. For each clause: the wording as it should appear, what it commits the vendor to, the weak version to reject, and the number to ask for. The specimen wording is drawn from our own agreement, lightly generalised; you are welcome to lift it.

Clause 1 · Freshness

Clause 2 · Coverage

Clause 3 · Quality

Clause 4 · Detection and repair

This is the clause almost no vendor volunteers, and it is the one that decides how much a breakage costs you. Sources change structure about 2.6 times a year each. At 40 sources that is a break every three or four days. What matters is not whether breaks happen but how long each one runs before it is caught, and how long it stays broken after that.

Clause 5 · Schema stability

Clause 6 · Support

Clause 7 · Reporting and remedies

Clause 8 · Exclusions and exit

Read this one last and most carefully, because it is where good clauses go to die.

Uptime SLA vs data SLA, side by side

The same five situations, under the two kinds of agreement. The uptime SLA column is the opening example; the data SLA column is the eight clauses above.

The pattern is that an uptime SLA makes every real failure either invisible or excluded. Which is not a reason to distrust the vendor. It is a reason to insist the document describe the service you are buying.

How ours reads, and what to ask us

The specimen clauses above are a lightly generalised version of the agreement behind our dedicated data acquisition teams, so it is fair to say where the real numbers land and where you should push.

• Freshness: 95% of scheduled deliveries on time. Coverage: at least 97% of expected records per source per run. Quality: 99% of records pass validation, duplicates under 0.5%, verified against six validation layers on every delivery.
• Detection and repair: breakages detected within 4 hours and fixed within 24 business hours, with the window re-collected. Schema: 30 days' notice for breaking changes. Support: 2 business hours, with IST overlap for US and UK mornings, in a shared channel.
• Remedies: service credits capped at 25% of the monthly fee. SLAs start after the onboarding month, because the first month is spent establishing the baselines the SLA measures against.
• Exit: you keep the code and the data, after the pilot and after any term.

Three things worth asking us, or any vendor, before signing. Ask for the exclusions list in writing, and read it against clause 8. Ask what the internal SLO is behind each SLA number. And ask to see a real weekly source-health digest from a current client, with the client's name removed, so you know what the reporting in clause 7 looks like in practice rather than in a schedule.

If the numbers above are more than you need, that is useful information too. A one-off dataset does not need a repair clock; our web scraping services page is the right starting point for that, and enterprise web crawling for very large one-time crawls. The maths on when an ongoing team beats an in-house hire is in the true cost of an in-house web scraping engineer. And every source, under any of these arrangements, goes through a terms and robots review first, as set out in web scraping laws and ethics.

Two places where these clauses are running in production: a daily hotel rate pipeline across OTAs, where the freshness clause does the work, and a continuous tyre pricing feed, where schema stability matters most because the data feeds a pricing model directly.

Frequently asked questions

Related reading

Specimen clauses are illustrative and not legal advice; have your counsel adapt them. Figures current as of October 2026.