DCheck Crawl Coverage

Compare extracted records with the exact IDs or URLs you expected. Detect missing pages, duplicate IDs, unexpected records and text below your chosen character threshold before passing the data to another workflow.

$0.05 per completed coverage report, including platform usage. One report checks up to 1,000 expected IDs against up to 1,000 supplied records. Both pass and fail reports are useful completed checks and trigger one report event. unknown reports do not trigger that event. There is no separate start or per-record event. Separate runs are separate requests; set a maximum cost of at least $0.05 per run.

Example

{
  "expectedIds": ["https://example.com/a", "https://example.com/b"],
  "records": [
    {"url": "https://example.com/a", "text": "First extracted page."},
    {"url": "https://example.com/a", "text": "A duplicate page."}
  ],
  "minChars": 10,
  "manifestComplete": true,
  "captureComplete": true
}

Two rows do not prove that both requested pages arrived: this synthetic example returns status: "fail" with a missing /b and duplicate /a. Both texts meet the chosen length threshold. The number of rows is correct; the set of pages is not.

To try it in Console, open Input, switch to JSON, paste the example above and run it. Use 256 MB memory, a 60-second timeout and a maximum cost of $0.05. Open the output report or the dataset row to see the result. This example is a paid report at the same $0.05 price.

Input

• expectedIds: up to 1,000 unique, nonempty strings. Supply the complete manifest for the scope you want to check.
• records: up to 1,000 extracted JSON records. The entire input must be at most 5 MiB.
• idField and contentField: simple top-level field names, default url and text. Set contentField to markdown if that is the field you supply.
• minChars: minimum length of trimmed text in Unicode code points, default 100; range 1–100,000. This is a length check, not a judgment of usefulness or factual accuracy.
• manifestComplete and captureComplete: required booleans. Only set them to true if the manifest covers your intended scope and your supplied records include the entire dataset export. Partial or unconfirmed inputs return unknown.
• excludedIds: optional unique subset of the manifest, explicitly removed from the checked scope. Records for these IDs are counted as excluded.
• aliases: optional explicit mappings such as [{"from":"redirected-url","to":"expected-url"}]. The source must not be a manifest ID; the target must be an included expected ID. No alias chains or inferred redirects.
• allowEmpty: default false. An empty effective manifest requires explicit opt-in.

IDs are compared exactly, including query strings, trailing slashes and leading zeros. Unknown input fields and invalid limits cause the run to fail. No pages are fetched, no external model is called and no dataset is downloaded automatically. Do not include secrets or data you are not permitted to process.

Output and workflow behavior

The Actor writes a JSON report to the default key-value store under OUTPUT, the same report as one row in the default dataset, and a human-readable preview under REPORT.html. The Console output links open the preview and the JSON. The preview uses no scripts or external assets. The input form includes a synthetic two-record example; replace it with your own scope and records. Running an example uses the same report price.

• pass: all declared conditions passed within the supplied scope.
• fail: a complete supplied scope contains one or more detected issues.
• unknown: either completeness flag is false; detected issues are still reported.

An Apify run marked SUCCEEDED means the report was generated. Check the report's status before allowing downstream processing. A fail or unknown report is still a successfully generated report.

The report includes scope, aggregate counts, and up to 100 issue details. Totals remain complete even when detailsTruncated is true. Text bodies are not copied into the report; IDs and URLs may be included. Input is still stored by Apify under its storage policies. The report does not verify freshness, the live website, semantic relevance, factual accuracy or reuse rights. A crawler's skipped-URL list can help explain a missing page, but does not make it present.

Using the result in an automation

1. Finish your extraction and export its records. Keep the original list of expected IDs or URLs.
2. Send that list and the records to this Actor. Confirm both completeness flags only when the supplied scope is complete.
3. Read OUTPUT.status. Continue downstream on pass; inspect counts and issues on fail; complete the input scope on unknown.

Use Apify Console or the Actor's API integration with your own credentials. This Actor accepts supplied records directly; it does not fetch another Actor's dataset. No external AI API key is needed.

Billing and support

The report event is requested after both report files and the dataset row are saved. A BILLING record explains whether the event was acknowledged, skipped, blocked or unconfirmed; it is a technical status, not a payment receipt. Repeated billing requests within one run use the same idempotency key. Creating a new run is a new request.

For help, open an issue on this Actor with the run ID and a minimal synthetic example. Do not post access tokens, private data or full customer datasets. This is a new tool: no customer results, savings or availability guarantees are claimed.