Skip to main content

Execution runs

An execution run is one run of a validation. It starts when you press Run on a validation, an asset, or a single rule, when a schedule fires, or when an integration calls the API. While it runs it fills in asset by asset; when it finishes it records a pass or fail for every rule it executed and a health score for the run.

Every run is read-only on your data source: Measured Cloud reads your data and records results, and never changes anything in the source.

What a run does​

  1. Start. The run plans exactly what it executes: the validation's enabled rules — every rule the validation holds — grouped into one pass per asset. The plan is fixed now: a rule added to the validation while the run is going waits for the next run. A disabled rule doesn't run.
  2. Execute. Each pass checks its rules together, through its data source's own mode: a direct source runs in the Measured Cloud worker; an agent-mode source runs inside your network through the Privacy Agent. One validation can mix both (see Validations → What a run executes).
  3. Record. Each pass's outcome lands as a result with a pass or fail per rule, failing counts, and sample failing rows where the rule type captures them. Every result is matched to the rule that produced it by the rule's own identity, never by position.
  4. Finish. When the last pass reports back, the run is rolled up: its status, its health score, and the change since the previous run. Alert rules that watch the validation are evaluated against the run's results and notify the channels they point at.

Agent-mode assets finish asynchronously — whenever your agent next polls — so a run that includes them stays running until the last agent asset reports.

Asset and rule runs​

Every run is an execution run of some validation, including the ones you start from an asset:

  • An asset's ▶ Run (on its page or its Data Assets row) runs the asset's default validation, which holds every rule on the asset. The run records trigger asset.
  • A single rule's ▶ Run runs the same default validation, restricted to that one rule. The run records trigger rule and the rule in its rule filter (rule_ids).

Both work for direct and agent-mode data sources. A single-rule run on an agent-mode asset sends only that rule to your on-prem Privacy Agent, so you can check one rule without re-running the whole asset.

Because they are ordinary execution runs, asset and rule runs show up in the default validation's Run history, count toward its health score, and can trigger alerts scoped to it.

Legacy checkpoint runs. Runs from before checkpoints were retired are kept. They stay on the Results page, labelled as asset runs, and are also filed as execution runs with trigger asset under the validation their checkpoint maps to. See Checkpoints (retired).

Watching a run​

Open the validation. Its Run history lists every run, newest first: its status (Passed, Failed, Stopped, or Nothing to run), its health, and its run time. It is the only run list on the page, so every run you've made is there, including runs from before the execution-run model.

  • An in-progress run expands automatically and fills in asset by asset.
  • Click a run to open its page, Validation run, with the failing counts, per-asset results, sample failing rows, and root-cause analysis.
  • Use a run's chevron to expand its per-rule breakdown in place, grouped by asset. Each asset links to its page, and each rule links to the asset with that rule focused — the fastest way from a failure back to where the rule is defined.

A run that failed before it could check any rule (for example, the data source was unreachable) says so on its page — "Failed before any rule was checked" with the reason — instead of reading "0 rules failed".

Stopping a run​

While a run is in flight, every ▶ Run control for it turns into a spinning Stop — on the validations list, the validation page, a schedule's Run now, an asset's Run, and a single rule's Run. The state comes from the server, so the control keeps spinning after a refresh and when the run was started somewhere else (another tab, the command palette, a schedule, a teammate).

What a Stop stops depends on where you press it:

You press Stop on…While…It stops
A validationits run is in flightThe whole run.
An asset or one of its rulesa validation run is on that assetOnly that asset's part. The validation carries on with its other assets, and the asset reads Cancelled in the run.
An asset or a ruleits own asset or rule run is in flightThat run.

Stopping is cooperative: the asset currently running is interrupted within a few seconds (it records no result), and the assets still waiting are cancelled. An asset already running on your on-prem Privacy Agent can't be interrupted from the cloud, so it finishes there. The control reads Stopping… until the run winds down. Anyone who can run the validation can stop it.

Runs you start from the app — from any button or the command palette's Run validation… — show a toast when they start and when they finish, even if you've moved to another page. Scheduled runs and runs other people start don't.

Health score​

Each finished run carries a health score from 0 to 100: that run's own pass rate, the share of the rule checks it evaluated that passed. It isn't weighted by severity or blended with earlier runs. The validation's headline health is a separate number: the pass rate over all of its runs in the last 30 days. See Health score.

A run that fails before evaluating any rule (for example, the data source is unreachable) still finishes and updates Last run, but produces no score, so an infrastructure blip never zeroes a healthy validation.

Run statuses​

StatusMeaning
runningThe run is in flight: assets are executing, queued, or waiting for the Privacy Agent.
succeededThe run finished. Its health score and per-rule results say how the data fared.
failedThe run finished with failures, or an asset errored before its rules could run.
cancelledThe run was stopped. Assets that had already finished keep their results.
skippedNothing ran: when the run started, the validation had nothing to execute (for example, a scheduled run that fired after its rules were removed or disabled).

A run's status says whether it finished; its health score and per-rule results say whether your data passed.

API​

POST /api/v2/organizations/{org_id}/workspaces/{ws_id}/validations/{validation_id}/run
POST /api/v2/organizations/{org_id}/workspaces/{ws_id}/validations/{validation_id}/run/cancel
GET  /api/v2/organizations/{org_id}/workspaces/{ws_id}/validations/{validation_id}/execution-runs
GET  /api/v2/organizations/{org_id}/workspaces/{ws_id}/execution-runs/{run_id}
GET  /api/v2/organizations/{org_id}/workspaces/{ws_id}/execution-runs/{run_id}/results
GET  /api/v1/organizations/{org_id}/workspaces/{ws_id}/active-runs
POST /api/v2/organizations/{org_id}/workspaces/{ws_id}/data-assets/{asset_id}/rules/run
POST /api/v2/organizations/{org_id}/workspaces/{ws_id}/data-assets/{asset_id}/rules/{rule_id}/run

Each run in the list (and the single-run read) carries result_id, the run's Validation run page, and its own rule-check counts: checks_evaluated and checks_failed, summed over its per-asset results (null when the run has no result to count from). The validation page's Failures chart plots checks_failed. The list pages with limit and cursor like other lists; ?limit=1 returns just the newest run.

POST .../run returns 202 Accepted with execution_run_id (the run to poll) and parent_result_id (the handle run/cancel takes). Its optional body restricts the run to some of the validation's rules (rule_ids). A run records what started it (trigger: manual, schedule, api, asset for an asset's Run or a legacy checkpoint run, or rule for a single rule's Run), its schedule, and any rule subset (rule_filter); total_assets / completed_assets count its passes. active-runs lists everything currently in flight in the workspace — it's what keeps the Stop controls in sync. See the API reference.

The two data-assets/.../run calls start an asset run and a single-rule run. Both return 202 with {"data": {validation_id, parent_result_id, execution_run_id, execution_mode, status: "pending", trigger, rule_ids, run_queue_id: null, checkpoint_id: null}}: validation_id is the asset's default validation, trigger is asset or rule, and rule_ids is the rule filter of a single-rule run. run_queue_id and checkpoint_id are deprecated and always null. Stop either with POST .../validations/{validation_id}/run/cancel and the parent_result_id. Running a validation, an asset, or a rule, and stopping a run, needs the can_run_validation permission (editor and above).