Data coverage

Everything on this page is measured live against the production index. Nothing is a screenshot, a claim, or a number typed in by hand.

Four questions, in the order most people ask them:

1. How much is there? The tiles.
2. Do you have my slice? Search a job title, or break the corpus down by any dimension.
3. Do you track my companies? Switch the search to Companies and type a name.
4. Is it any good? Freshness and quality signals are further down this page.

Using the explorer

Two things worth knowing. Picking a second value on the same dimension replaces the first rather than adding to it — a posting cannot be in two countries at once. And the tiles always describe the whole corpus; the filtered total appears under the chips, because the hourly rollup behind the tiles counts the index rather than your query.

Why the tiles and the filtered total come from different places

Headline totals prefer an authoritative rollup over a raw index count. The indexes are continuously rebuilt, so an unfiltered index total under-reports while a rebuild is in flight. Every response is therefore stamped with the hourly jobfront_metrics rollup (rds_total_count, rds_total_past_7d, rds_sources_total_count) and the tiles prefer it, which is why the number here matches the number in the dashboard.

Break it down by

The chips come from the live segment registry rather than a hardcoded list, so what you see on the page is the authoritative set.

Metro, State and City come back grouped by their parent — cities under their state, states under their country — because there are a dozen Springfields.

Bars scale to the largest bucket in view, not to the total: job data is long-tailed, and scaling to the total collapses every bar after the first into a sliver. Read the bars for shape and the numbers for magnitude. The share column beside each count is additive. "Still in the tail" is what fell outside the returned top-N — a large tail is normal for occupation, skill and city, and walking one properly is what the V4 API is for.

Three segments deserve a note on how their buckets are built.

How fresh is it?

Postings are discovered by crawling company job boards directly, then parsed, enriched and made servable on the same pass. There is no overnight batch between ingest and availability, which is why the median posting age is a number about the market rather than about our pipeline.

What each number means

Active jobs

Postings that are servable right now: job_status: active in the jobs index. This is the denominator for everything else on the page, and the population every breakdown above divides up. It is the same active-posting predicate the public API applies, so a total you read here lines up with a total you get back from /v4/jobs — the same corpus, filtered the same way.

Companies

Sources that are both active and have a tracked job board (is_active and has_jobboard). Company profiles we track but do not scrape are deliberately excluded — counting them would inflate the number without adding a single retrievable posting.

Ingested last 24h

Active postings whose created_at — the timestamp we first saw the posting — falls in the last 24 hours. It is deliberately not updated_at: a re-scrape that touches every record would otherwise read as a giant ingest spike. The sparkline is the same window as a per-hour histogram, zero-filled across all 24 buckets so a quiet stretch renders as a flat line rather than a gap.

Median posting age

The p50 of created_at across the active corpus, expressed in days. A median, not a mean: job data has a long tail of evergreen listings that sit open for months, and a mean would let that tail drag the number well past what a typical live posting looks like.

Job-board platforms

The count of distinct job-board formats parsed across those sources.

Quality signals

Coverage answers how much. These answer how good — three genuinely different things, reported separately rather than blended into a single score that would mean nothing.

Source quality bands describe how rich the underlying posting was. A low band is usually a thin posting — a title and a link, with little to enrich from — rather than a failed parse. Filter on data_quality_band if your use case needs the richer end of the corpus.

Workplace classifier confidence is per-record rather than a global claim. The enrichment models emit a confidence between 0 and 1 on every workplace tagging, and set conflicting when the signals in a posting actively disagreed. A high conflict rate on a slice is the pipeline telling you it was unsure, which is more useful than a confident guess. Both are on the object, so you can require agreement rather than trusting a coin flip.

The sample panels

Representative jobs is a random recent slice, not the head of the index — the sample is drawn with a random score, so it changes between refreshes and you see the ordinary case rather than a curated one. With no filters applied it is held to a quality floor (recent, with a location, compensation and a description) so the panel shows what a populated row actually looks like. Applying a filter drops those floors — layering them on a narrow query would frequently return nothing.

The response is trimmed before it leaves the service: raw posting HTML, the full extracted dictionary, internal ids and computed scores are removed, descriptions are capped at 600 characters, and posting URLs are stripped — retrieving those is what the API is for.

Top companies ranks by active job-board job count, restricted to active companies with a tracked job board and at least one active job. With a job-title search applied it changes meaning and ranks companies by how many matching jobs they have — "who is actually hiring for this role".

The coverage API

PUBLIC ENDPOINTS

Everything the explorer renders is available as JSON. These endpoints are public, read-only, aggregate and PII-free, and they are served by the docs host rather than by api.jobfront.com. No token is required. Each is also reachable under the /api/data-coverage/... prefix.

Filters compose across segments

filters takes a JSON object on the query string; the same keys are also accepted as individual query parameters. Filters apply to every endpoint that takes them, and they compose — narrow by country and remote flag, then break the result down by occupation.

curl -sG https://docs.jobfront.com/data-coverage/segment \
  --data-urlencode 'segment=job_onet_code' \
  --data-urlencode 'top_n=10' \
  --data-urlencode 'filters={"location_country":"us","is_remote":true}'

Checking whether a company is tracked is the same call against sources:

curl -sG https://docs.jobfront.com/data-coverage/sources \
  --data-urlencode 'filters={"search":"stripe","search_scope":"sources"}'

Recognised keys are search, search_scope, search_in_description, posted_window, job_category, job_department, job_level, job_commitment, job_workplace_type, job_industry, source_industry, job_skill, technology_slug, team_family, job_onet_code, ats_family, data_quality_band, location_country, location_state, location_city, location_cbsa, source_brand_name, is_remote, is_internship and is_offers_visa_sponsorship.

Anything else is dropped before the request reaches the cluster. Free text is trimmed to 120 characters, and a description-scoped search shorter than 3 characters silently loses the description scope — at that length it is a near-full-text scan, and the title-only path still answers.

The live aggregate endpoints

A second family answers the unfiltered, whole-corpus questions — the numbers behind the tiles and the freshness row above. They take no filters. Same guarantees as the rest: public, read-only, aggregate, PII-free, served by the docs host, no token.

curl -s https://docs.jobfront.com/docs/live/summary

One further endpoint runs a whole-corpus aggregation. It is much wider than the ones above and is cached for one hour rather than 60 seconds:

Response keys on /docs/live/summary

Cross-origin GET is allowed on purpose: these are aggregate, non-sensitive numbers and you are welcome to build your own dashboard on them.

Guardrails

Each call fans out to a live cluster aggregation, so the endpoints are guarded. All of these limits are enforced per worker, so treat them as protection against abuse rather than as a published quota:

User-controlled knobs are clamped rather than trusted. top_n defaults to 25 with a hard ceiling of 500, and the expensive high-cardinality segments — skill, occupation, city, metro, state, top companies and the flag slices — are capped lower still. limit on the jobs and sources endpoints defaults to 12 and is clamped to a maximum of 20.

If you need more than these endpoints comfortably give you, that is what the API is for — start at Get started and the V4 API reference. The v4 API has its own, separate limits — see Rate limits and billing.

When a panel is empty

Each panel on this page owns its own fetch and its own failure. A slow or failing aggregation greys out one card and offers a retry — it never blocks the page, and the documentation around it stays correct. Requests that take longer than 8 seconds are treated as a failure by the widget.

You will never see a stale number without a timestamp, and never a zero standing in for a missing value: an unavailable number renders as an em dash. If a panel is greyed while the rest of the page is fine, that is one aggregation timing out, not an outage.

Related

• Data dictionary — all ~57 fields with their types, absence contracts and provenance.
• How we get the data — the pipeline that produces everything counted here.
• Data quality — how the pipeline monitors itself.