A web scraping SLA should measure the delivered data.

A web scraping SLA should measure whether accepted data arrived by the agreed deadline, was fresh enough at handoff, covered the defined scope, satisfied the required quality rules, and was restored and corrected within agreed times after a failure. It should not be reduced to crawler uptime, HTTP success, or the time taken to acknowledge a support ticket.

The distinction is commercial, not semantic. A scraper can be available while it returns yesterday’s data, misses an important source, shifts values into the wrong fields, or uploads a partial batch. None of those outcomes is useful to the team consuming the feed. A well-designed service-level agreement makes the delivered data observable, defines how each result is calculated, and states what happens when the commitment is missed.

There is no universal web scraping SLA percentage that every buyer should demand. Targets depend on the source estate, collection cadence, business consequence, recovery options, and results from a representative pilot. The reusable part is the measurement design: every promise needs a service object, formula, denominator, clock, window, evidence source, exclusions, and breach action.

Measure the data outcome, not crawler uptime

Start by describing the recurring data service the customer expects to receive. For example:

Deliver the approved product records from the versioned retailer scope to the agreed destination each business day, inside the delivery window, with a run manifest, source-observation timestamps, acceptance results, reason-coded exceptions, and a correction and replay process.

That statement identifies more than a running system. It names the scope, cadence, destination, acceptance boundary, and evidence. The exact service object may be a daily snapshot, an event stream, a rolling update, a historical backfill, or a set of source partitions. Whatever the form, both parties need to recognize the same unit when counting a success or failure.

Define the following before choosing a percentage:

• the sources, locales, entities, fields, history, and discovery boundary included in the service;
• the delivery cadence, deadline, time zone, business calendar, destination, format, and schema version;
• the acceptance rules that separate accepted, quarantined, rejected, and partial output;
• the timestamp that represents observation at the source and the timestamp that represents acceptance at the destination;
• the buyer dependencies, such as credentials, approved scope, reachable storage, and timely change decisions;
• the provider responsibilities for collection, validation, delivery, incident response, correction, and backfill; and
• the change-control process used when a source, schema, cadence, or destination changes.

Keep that definition versioned. If the source list grows during a measurement window, the denominator should not change informally in the middle of the period. Record when the new scope becomes effective and which version governed each run.

Google’s SRE guidance recommends a small number of indicators that reflect what users care about. For data-processing pipelines, it identifies throughput, end-to-end latency, and correctness as more meaningful than internal availability alone. That is a strong starting principle for a scraping service, even though the exact indicators must be adapted to the feed. (Google SRE: Service Level Objectives, Google SRE: Data Processing Pipelines)

This article turns that operating principle into a contract measurement schedule. Use the web scraping vendor selection guide to evaluate the provider and its evidence before award; use this SLA structure to convert the proven outcomes into continuing commitments.

Define each service level before setting a target

Keep three concepts separate:

A service level indicator (SLI) is the measured result: for example, the proportion of eligible scheduled deliveries accepted by their deadline.

A service level objective (SLO) is the target or acceptable range for that result during a stated window.

A service-level agreement (SLA) connects the commitment to consequences: reporting, corrective work, governance, credits or service points where appropriate, and rights after repeated or serious failure.

Google’s SRE material makes this separation explicit and warns that an SLA without an objectively measured SLI is difficult to enforce or improve. Its implementation guidance also distinguishes the SLI specification from the implementation that produces the measurement. That distinction matters when a vendor dashboard and a buyer’s destination log disagree. (Google SRE: Implementing SLOs)

Every service level should therefore fit into one complete metric record.

For each commitment, write down:

1. Service object: the feed, source group, field set, delivery, record, or incident being measured.
2. Success condition: the precise event that enters the numerator.
3. Eligible population: the denominator, including how partial, duplicate, cancelled, and previously failed events are treated.
4. Measurement point: the system and event that establish success, such as destination acceptance rather than vendor upload.
5. Clock: start, stop, pause, time zone, calendar, and timestamp source.
6. Target and window: the objective and the period over which it is evaluated.
7. Aggregation: whether results are calculated globally, by source tier, by delivery, by field, or with a critical-source floor.
8. Exclusions: narrow, reason-coded conditions and the evidence required to apply them.
9. Evidence and reconciliation: the report, event log, retention period, owner, and dispute procedure.
10. Breach action: the operational response, correction, remedy, escalation, and chronic-failure rule.

NIST’s cloud service metric model is broader than web scraping, but its discipline transfers well: a usable metric needs an expression, unit, measurement rules, and constraints that make results representative, reproducible, and comparable. A label such as “accuracy” or “uptime” is not yet a metric. (NIST SP 500-307)

Write the formula and counting rules before the target. Otherwise a precise-looking percentage can conceal a negotiable denominator.

1. Accepted delivery

Accepted delivery measures whether a usable output reached the agreed destination on time. It is stronger than crawler completion, file creation, or an attempted upload.

Define “accepted” through observable conditions. A delivery may need the correct feed and schema version, a complete manifest, a matching checksum, the expected partitions, and passage through critical acceptance rules. If the destination exposes an acknowledgement, record that event. If it does not, specify the alternative evidence and how the buyer reports a receipt failure.

The denominator should begin with the delivery calendar, not the vendor’s job log. A scheduled delivery that never starts must still be visible. State how approved cancellations, buyer-requested pauses, duplicate uploads, replacement files, and split deliveries are counted. A partial batch should not become a full success merely because one file arrived.

Decide what happens when one source partition is late. Three defensible designs are possible:

• the whole scheduled delivery fails acceptance until every required partition passes;
• each named partition is measured independently, with an overall floor for critical sources; or
• the accepted portion is released while the missing portion remains an open failure with a stated correction deadline.

The choice depends on consumer behavior. If the downstream process cannot safely distinguish a partial dataset, whole-delivery acceptance is clearer. If consumers can isolate partitions, separate measurement may preserve useful data without hiding the missing scope.

Do not use infrastructure uptime as a proxy. A provider API can respond throughout the day while the required delivery is absent. Uptime can remain an internal operational objective or an additional platform commitment, but it cannot establish that the contracted data outcome occurred.

2. Freshness and timeliness

Delivery timeliness and record freshness answer different questions. Timeliness asks whether the output arrived by its deadline. Freshness asks how old the represented source observation was when the output was accepted.

Define the source observation timestamp carefully. It may be the time the relevant page was successfully observed, the time an upstream item declares that it was updated, or another agreed event. A pipeline processing timestamp is not automatically evidence of source freshness. If the source provides no reliable event time, state what the collection timestamp represents and its limitations.

Segment freshness where the business consequence differs. A daily price feed may need a tighter window for priority retailers than for long-tail sources. A single average can allow very fresh easy records to mask a stale critical partition, so report the distribution and the result by agreed source tier. Where a record contains fields observed at different times, define whether freshness applies at record level, field level, or to a named critical subset.

Late and stale are not interchangeable. A late delivery might contain current source observations; an on-time delivery might repeat an old accepted snapshot. The measurement schedule should show both states and say whether either condition blocks acceptance.

Avoid promising a cadence the source cannot support. A representative pilot should observe normal and difficult collection cycles, source publication behavior, access variability, and destination latency. Set the target from the decision’s time sensitivity and the demonstrated operating envelope—not from an unsupported “industry standard.”

3. Scope coverage and completeness

Coverage asks whether the service observed the agreed source or entity universe. Completeness asks whether required fields were populated for the records to which those fields apply. Combining them into one percentage creates a loophole: a provider can report complete fields for the small subset it managed to collect.

Coverage needs an explicit denominator. For a fixed source list, that may be a versioned inventory of URLs, sellers, categories, locations, or identifiers. For discovery work, a complete real-world population may be unknowable. In that case, define an observable discovery procedure and proxy denominator: approved seed pages, pagination paths, query sets, category traversal, previous known entities, and reason-coded additions or removals. Do not claim complete market coverage when the measurement can establish only process coverage.

Reconcile each expected item into a mutually exclusive state such as observed, legitimately absent at source, unavailable, excluded by approved scope, failed, or unresolved. Failed and unresolved entities must remain in the denominator unless an agreed exclusion applies. Otherwise the service can improve its reported coverage by ceasing to count hard targets.

Completeness also requires semantics. Define required and optional fields, applicable cases, valid null reasons, and whether an empty string, zero, placeholder, or inferred value counts as populated. Report important fields separately. A strong aggregate can hide a critical price or identifier field that is regularly absent.

Validity is related but distinct:

A date can be present and still invalid; a valid decimal can still be attached to the wrong product. The UK Government Data Quality Framework treats quality as fitness for purpose and distinguishes dimensions including completeness, timeliness, validity, and accuracy. It also emphasizes actions, owners, and monitoring rather than assuming one score fits every dataset. (Government Data Quality Framework)

Use the web scraping data-quality QA framework to design the actual rules, sampling, quarantine, and acceptance process. The SLA should import only the dimensions important enough to become service commitments; it should not reproduce the complete QA test suite.

4. Source fidelity and correctness

Source fidelity asks whether the delivered value matches the agreed source fact and interpretation. It is not established by schema validity. A plausible price can come from the wrong seller, an old variant, a crossed-out list price, or a currency conversion that the specification did not authorize.

Specify the unit of observation. A record-level pass may require every critical field to agree; a field-level measure counts each audited field independently. If some fields have materially different consequences, give them separate results and floors rather than letting many easy fields dilute one critical failure.

The metric schedule must define:

• which source representation and timestamp serve as the reference;
• the interpretation rules for variants, ranges, promotions, unavailable values, units, and derived fields;
• who selects the sample and whether it is stratified by source, field, risk, change, and edge case;
• the sampling period, sample unit, evidence retained, and treatment of inaccessible historical states;
• the tolerance for numeric or time comparisons where exact equality is inappropriate; and
• how disagreements, ambiguous pages, transformation defects, and genuinely changed source values are adjudicated.

A provider-selected convenience sample is not enough. The buyer should be able to reproduce or independently inspect a risk-based sample, including important sources and known difficult cases. Automated rules can expand coverage, while source-to-output review tests semantic correctness that structural checks cannot prove.

Do not promise universal accuracy or quietly remove disputed observations. Report the numerator, denominator, exemptions, error categories, affected sources and fields, and confidence limitations. Google’s SLO implementation guidance notes that pipeline correctness may require comparison with known outputs or an independent sample, while coverage can be difficult when the true denominator is unknown. Those limitations should be designed into the measure, not buried after a breach. (Google SRE: Implementing SLOs)

5. Incident recovery and backfill

An incident commitment needs more than “priority support.” Separate the clocks because they describe different customer outcomes.

Define at least these events where they matter:

• detection: the provider’s systems first identify the missed outcome;
• notification: the buyer receives the required facts through the agreed channel;
• acknowledgement: an accountable operator accepts ownership of the incident;
• containment: questionable data is held, isolated, or marked so it cannot silently contaminate downstream use;
• usable restoration: the feed resumes at an agreed safe level, possibly through a temporary workaround;
• corrected redelivery: affected output is replaced and passes the complete acceptance process; and
• backfill completion: the recoverable missing interval is replayed, deduplicated, revalidated, delivered, and reconciled.

Ticket acknowledgement is not restoration. Restoration is not necessarily correction. Correction is not complete until the affected historical window has been reconciled or the unrecoverable gap has been declared. Reporting these clocks separately prevents a fast support response from disguising a slow data repair.

For every clock, define its trigger, stop event, severity, coverage calendar, pause conditions, and evidence source. State who can change severity, what buyer dependency pauses a clock, and when it resumes. If a source state is transient and cannot be reconstructed, the provider should document the gap rather than fabricate a backfill.

Recovery scope also needs an economic boundary. Say which replay and correction work is included, how long source evidence and raw observations are retained, when a buyer-requested historical rebuild becomes a change, and how duplicate prevention is verified. Link recovery priority to the actual business consequence, not only to the technical component that failed.

NIST’s contingency-planning guidance is not a scraping SLA template, but it provides a useful discipline: connect recovery priorities to business impact, define recovery procedures, and test the plan rather than relying on an unexercised promise. Apply that logic proportionately to the feed and its consumers. (NIST SP 800-34 Rev. 1)

The web scraping monitoring runbook defines the signals and operational actions used to detect, contain, repair, and validate incidents. The SLA selects which user-visible outcomes and clocks become commitments; it should not prescribe every diagnostic step.

Set targets, windows, and exclusions

Choose targets only after defining the measure. Use the business consequence of failure, observed source behavior, representative pilot results, recovery alternatives, and price of additional resilience. A target that cannot be measured or sustained creates negotiation theater; an easy target that does not protect the decision creates false assurance.

The window changes the meaning of the objective. A monthly aggregate can permit several consecutive misses at the worst possible moment. A per-delivery commitment can overreact to isolated low-impact variation. Depending on the use case, combine an aggregate objective with one or more guardrails:

• a per-delivery or per-source critical floor;
• a maximum consecutive-failure rule;
• a separate result for priority sources or critical fields;
• a rolling window that reveals deterioration earlier; and
• an immediate material-incident trigger independent of the percentage.

Show the result by relevant segment as well as in aggregate. Easy sources must not compensate for a failed critical source, and high-volume optional fields must not compensate for a missing required field. Freeze the denominator after the measurement window closes and retain the underlying event list so both parties can reproduce the calculation.

Exclusions should be narrow, pre-defined, reason-coded, evidenced, and visible in the report. Plausible categories can include an approved service suspension, a documented buyer destination outage, buyer-controlled credentials that were not supplied after notice, or a genuine third-party source outage that made the relevant content unavailable through the approved method. Even then, the parties should decide whether notification, evidence, partial delivery, and recovery clocks still apply.

Do not turn normal source change into a blanket exclusion. Website redesigns, access variation, parser breakage, and anti-automation changes are foreseeable features of operating a web scraping service. They may affect price, risk allocation, and an agreed feasibility boundary, but automatically erasing every such event from the denominator would remove much of the service the buyer intended to purchase.

Also distinguish an inaccessible source from a provider failure to observe an accessible source. Preserve dated evidence and apply the reason code consistently. Cap or review prolonged exclusions so a chronically unavailable critical source triggers a scope, method, price, or termination decision instead of disappearing indefinitely.

The UK Government Sourcing Playbook is designed for public procurement, not as private-sector legal advice. Its broader principles remain useful here: specifications and KPIs should be clear and proportionate, risk should sit with the party best able to manage it, and risk allocation should support delivery rather than transfer obligations mechanically. (UK Government Sourcing Playbook)

Use the web scraping total-cost-of-ownership model and maintenance-cost guide to price resilience, retained buyer work, incidents, and change scenarios. Keep those economics visible beside the SLA rather than hiding them inside one service-level percentage.

Make the SLA reportable and actionable

The contract schedule should be executable as a recurring report, not interpreted from scratch after an incident.

For each measurement window, the report should show:

• metric name, definition version, target, and applicable source or field tier;
• numerator, denominator, result, and the event-level records needed to reproduce them;
• excluded events with reason codes, evidence, approver, and duration;
• failed deliveries, sources, fields, or observations and their business impact;
• incident timestamps for detection, notice, acknowledgement, containment, restoration, redelivery, and backfill;
• open corrections, unresolved gaps, chronic trends, and corrective-action owners;
• any credit, service point, escalation, or other remedy triggered; and
• changes proposed for the next window without rewriting the closed result.

Name the system of record for each event. Vendor telemetry may establish run completion; destination logs may establish receipt; validation reports may establish acceptance; retained source evidence may support fidelity review. Where the parties hold different records, define a reconciliation period, evidence-retention term, escalation path, and decision owner. WebTruffle’s synthetic sample data-quality report shows how acceptance results, quarantined exceptions, and delivery evidence can be separated in one inspectable artifact. It is an example format, not proof of a service result.

Use a remedy sequence that restores the outcome before debating the invoice. A practical order is:

1. prompt notice and containment;
2. workaround or usable restoration;
3. corrected redelivery and backfill;
4. root-cause analysis and a dated corrective-action plan;
5. service credit or service points where commercially appropriate;
6. enhanced governance after repeated misses; and
7. termination and transition rights for defined chronic or material breach.

Service credits can make failure visible, but they do not replace correction, backfill, evidence, or continuity. Define whether credits are automatic, how they are calculated, whether they are capped, and how repeated breach affects renewal or termination. Align the remedy with the consequence: a small credit is not meaningful protection if bad data can trigger a costly downstream decision.

Govern the SLA on a fixed cadence. Review results, incident trends, exclusions, open corrective actions, scope changes, consumer needs, and measurement reliability. Change targets prospectively through version control; do not revise a formula after seeing an unfavorable result. Revalidate important targets after a representative source or architecture change and before renewal.

Finally, plan the end of service. The measurement schedule should support export of recent accepted data, schemas, manifests, run history, open incidents, known gaps, correction status, and the evidence needed for a controlled handoff. The migration guide covers the cutover steps; the SLA should state the transition outcomes and assistance that survive termination.

Contract language, liability, credits, termination rights, and governing law require qualified legal and procurement review for the relevant jurisdiction. This guide is an operating and measurement framework, not legal advice. Its purpose is to make the promised operational data feed specific enough to measure, improve, and govern.

Frequently asked questions