Checks FAQ

Answers to questions that apply to checks of every rule type. Rule-specific questions live on each rule type's own FAQ page (see Getting Started with Checks).

Auditing check executions

How do I get a list of every check execution, passes included?

Use the enrichment datastore. Every scan writes one row per check, per partition, per scan to the _check_metrics output, with the result (passed, failed, or unasserted), the asserted and anomalous record counts, and any assertion details. That output has no timestamp of its own, so join it to _scan_operations on OPERATION_ID, CONTAINER_ID, and SOURCE_PARTITION = PARTITION_NAME to get the scan's START_TIME and END_TIME. The full query is in Joining scan outputs.

If you do not have an enrichment datastore, GET /api/quality-checks/{id}/insights gives a daily summary of a single check for up to a year at a time: the latest result of each day, the scan that produced it, and the day's totals. It is not a list of executions. When a check runs more than once in a day, only the last run's result is reported, so use the enrichment join when the audit needs every run.

Anomalies link back to the scan that produced them through the operation object on GET /api/anomalies/{id}, and GET /api/anomalies filters by operation, container_scan, and partition_scan. See the Anomalies API.

How do I see what a check looked like when a scan ran?

Take the scan's start_time (from GET /api/operations/{id}, GET /api/container-scans/{id}, or START_TIME in _scan_operations) and pass it as version_at to GET /api/quality-checks/{id}/version. The response is the complete check definition as it was at that instant. The created timestamp of an anomaly works the same way: it is what the app uses to show the check as it was when the anomaly was detected. For the list of every change in between, use GET /api/quality-checks/{id}/history.

The Export operation writes only the current state of each check, so use these two endpoints when an audit needs point-in-time definitions.

Why does a check show as passed in the per-scan results when it was not evaluated?

GET /api/operations/{id}/scan-checks and GET /api/container-scans/{id}/checks derive pass/fail from the number of anomalies the check produced in that scan. A check the scan could not evaluate produces no anomalies, so it appears as passed there. To tell unasserted apart from passed for a given scan, use the ASSERTION_RESULT column of the _check_metrics output. The check Insights endpoint also records the actual result, but only for the last run of each day. See List Check Results for a Scan.

Are the timestamps on a check UTC?

Yes. Every timestamp the API returns is UTC, formatted as ISO 8601 with a trailing Z. last_asserted is the UTC start time of the partition scan that last evaluated the check. See Timestamps.