When a job board evaluates a data provider, the conversation usually starts with listing volume, pricing, and update frequency. These are important considerations, but they do not establish whether the feed will be reliable enough to support the platform.
A provider may deliver millions of job records while leaving the board to deal with stale vacancies, missing fields, duplicate listings, inconsistent source coverage, or delayed updates. The resulting operational cost can outweigh the value of the additional inventory.
A Service Level Agreement (SLA) helps establish measurable expectations between a job board and its data provider. Rather than relying on broad assurances about quality or reliability, both parties agree on what will be measured, how performance will be evaluated, and what happens when commitments are missed.
Here are seven metrics every job board should consider when defining a job feed SLA.
1. Source Coverage and Availability
A large feed is only useful if it covers the employers, industries, locations, and job categories the board needs. Headline volume alone does not reveal whether important sources are missing or whether coverage is deteriorating. Job boards should distinguish between the number of sources configured, the number actively monitored, and the number consistently returning relevant listings. These are different measures, and a provider should be able to explain each one.
What to define in the SLA:
- Agreed source coverage across employers, geographies, and job categories.
- How active sources and successful collection are defined.
- How source outages or persistent collection failures are reported.
- How coverage changes are communicated and reviewed.
Coverage should be measured against an agreed scope rather than an undefined promise of comprehensive inventory.
2. Data Freshness
A new vacancy can appear on an employer’s career page before it reaches a job board. Similarly, a modified listing may continue appearing with outdated information if the feed does not capture the change promptly. Freshness measures how current the delivered data is. It should account for collection and delivery delays, not simply whether a provider updates its feed daily. For example, a daily feed schedule does not guarantee that every listing was collected recently. A record collected several days ago can still be included in today’s delivery.
What to define in the SLA:
- Expected collection and delivery frequency.
- How the age of a listing or update is measured.
- The percentage of records expected to meet an agreed freshness window.
- How freshness exceptions are reported, including sources that cannot be checked as frequently.
Job boards should select thresholds based on their operating model. A high-turnover job category may require different freshness expectations from a lower-volume, specialised market.
3. Required-Field Completeness
A job record may contain a title and description but still lack the information a job board needs to power its search filters, candidate experience, or downstream integrations. Missing employer names, locations, employment types, application URLs, or other required fields can create extra processing work and limit how listings are displayed. The important distinction is between fields that are genuinely unavailable at the source and fields that should have been captured or processed but were omitted.
What to define in the SLA:
- A documented schema identifying required and optional fields.
- Completeness rates for agreed critical fields.
- Rules for representing unavailable values.
- How schema changes and field-mapping issues are handled.
Completeness should be measured against the agreed schema, not against an assumption that every employer publishes every possible field.
4. Duplicate Listing Rate
The same vacancy may appear on multiple employer pages, arrive through overlapping sources, or be republished with a different URL or identifier. Without appropriate matching, a job board can receive several records representing the same opportunity. Duplicate listings inflate apparent inventory and create additional maintenance work. They can also frustrate job seekers who encounter repeated results.
What to define in the SLA:
- What constitutes a duplicate record.
- Which identifiers and matching attributes are used.
- How the duplicate rate is calculated.
- How exceptions, such as genuinely separate vacancies for the same role, are treated.
The measurement method matters. Two providers may report different duplicate rates because they use different matching rules. Agreeing on the methodology makes the figures comparable.
5. Job Closure and Removal Latency
Freshness and expiry management are related, but they measure different things. A listing can be recently collected and still be incorrect if the employer closed the vacancy before the latest collection. Removal latency measures the time between detecting a closure or other relevant source change and reflecting that change in the delivered feed. For job boards, this is directly connected to listing reliability. Late removals can leave unavailable vacancies visible, while delayed updates can preserve outdated application links or role details.
What to define in the SLA:
- How source closures and material changes are detected.
- The expected time to update or remove affected records after detection.
- How unavailable sources and uncertain closure signals are handled.
- How closure and removal performance is measured and reported.
The agreement should distinguish the provider’s detection and processing commitments from factors outside its control, such as a source that cannot be accessed.
6. Feed Delivery Reliability and Latency
Even high-quality data becomes operationally ineffective if it does not reach the job board when expected. Delivery reliability covers whether scheduled feeds or agreed integrations are available within the specified delivery window. Latency measures how long delivery takes. For API-based integrations, the SLA may also need to cover response times, timeouts, retries, and rate limits. A provider can meet its collection commitments but still create downstream problems if delivery fails or the receiving system cannot process the output.
What to define in the SLA:
- Scheduled delivery windows and acceptable delays.
- How successful delivery is confirmed.
- Retry, recovery, and replay procedures following failures.
- How partial deliveries, failed records, and integration errors are handled.
- The reporting window used to calculate successful delivery performance.
The agreement should reflect the actual delivery architecture, whether the job board consumes a file feed, an API, or another integration method.
7. Incident Response and Change Communication
Not every data issue can be prevented. Sources can change their website structure, integrations can fail, and upstream information can become temporarily unavailable. The important question is how quickly the provider identifies the problem, communicates its impact, and works toward resolution. A technically capable provider should have a defined process for reporting significant incidents and managing changes that could affect the receiving platform.
What to define in the SLA:
- Incident acknowledgement and update timelines.
- Severity levels and escalation routes.
- Restoration or resolution targets where appropriate.
- Advance notice for planned schema or integration changes.
- Post-incident reporting for significant or recurring failures.
A clear process helps the job board distinguish a temporary exception from a persistent issue requiring changes to the agreement or underlying implementation.
Turning These Metrics Into a Useful SLA
The seven metrics are most useful when they can be measured consistently and tied to an agreed operational process. Before finalising an agreement, job boards should establish a baseline using representative data, define how each metric is calculated, set targets appropriate to the use case, and determine how performance will be reported.
Targets should not be selected arbitrarily. They depend on source characteristics, market coverage, delivery architecture, required fields, and the board’s own freshness requirements.
The agreement should also specify exceptions, reporting periods, escalation procedures, and remedies for material breaches. Not every data-quality issue belongs in a contractual SLA, but the provider and board should agree on which measures are contractual commitments and which are operational KPIs used for continuous improvement.
How Propellum Fits Into the Job Feed SLA
For job boards, meeting service expectations starts before a feed is delivered. The underlying pipeline must collect from relevant sources, extract job information, standardise and validate records, manage changes, and prepare the data for ingestion.
This is the part of the process Propellum works on. We source job postings from employer career pages, process and validate the information, and prepare structured feeds for job boards to ingest into their platforms. The feed can then be assessed against the board’s requirements for fields, source coverage, update frequency, and delivery format.
These requirements are worth defining early. When both sides agree on the source scope, data structure, update expectations, and delivery method, it becomes easier to measure feed performance and identify where an issue originates, whether in source collection, data processing, or downstream integration.
Ultimately, a reliable job feed depends on clear expectations across the entire pipeline, not just the number of records delivered.
Conclusion
A job feed SLA should do more than promise regular delivery. It should define what reliable job data means for the platform receiving it. Source coverage, freshness, field completeness, duplicate rates, closure latency, delivery reliability, and incident response provide a useful starting framework. Together, they help job boards identify weak points, compare providers more consistently, and establish clearer operating expectations.
The objective is not to demand the same targets from every provider. It is to ensure that the targets reflect the board’s actual needs, are measurable in practice, and come with an agreed process for addressing failures. A reliable data partnership begins when both sides know exactly what success looks like.
The priorities depend on the platform, but freshness, source coverage, required-field completeness, duplicate rate, closure latency, and delivery reliability are strong starting points. Incident response and change communication are also important for operational continuity.
No. Delivery frequency describes when data is sent, not necessarily when it was collected or when a source change was detected. Job boards should separately define collection freshness, delivery schedules, and update or removal expectations.
They should agree on a matching methodology using available identifiers and attributes such as employer, title, location, and application URL. The duplicate rate should then be calculated over an agreed dataset and reporting period using those rules.
A job feed Service Level Agreement defines measurable service expectations between a data provider and a job board. It may cover source coverage, freshness, data completeness, delivery performance, incident handling, reporting, and remedies for missed commitments.
