Health score

A health score is the share of rule checks that passed, over the runs in a recent window:

health % = 100 × passed rule checks ÷ evaluated rule checks, over every run in the last 30 days.

The failure rate is its complement (100 − health %). It's the plain-language form you'll see beside the badge: "12% of checks failed in the last 30 days."

A rule check is one rule evaluated against one data asset in one run. A validation that runs 10 rules across 3 assets evaluates 30 checks per run. Checks are counted, not weighted: a failed info rule counts the same as a failed critical one. Severity still drives alerts and the dashboard's failed-checks-by-severity breakdown, but it doesn't change the health percentage.

Where it's shown

Surface	What the number covers
Validations list (Health (30d) column)	Every run of that validation in the last 30 days. The list cell shows the band plus the health % and failure % ("88% · 12% failed"), and how many runs failed when any did ("· 49/50 runs failed"). The validation's detail page doesn't show the score: its Failures card charts how many rules failed in each run instead (see Validations).
Data Assets list (Health (30d) column) and data asset detail (Health (30d) stat card)	Every run that checked that asset in the last 30 days: validation runs, the asset's own Run, and single-rule runs alike.
Dashboard (Health score card)	Every run in the scope you're viewing (workspace, team, or org), over the period the selector sets (30 days by default; 60, 90 days or 1 year on request). The same definition, with the period as the window.
A validation's Run history (the Health column on each run)	That one run only: its own pass rate. It isn't blended with earlier runs.

The badge shows a plain band: Good (above 90), Fair (70–90), Poor (below 70). Hover the info icon beside the badge to see the exact percentage and the counts.

Health counts checks, not runs. A run passes only when every one of its checks passes, so a validation with one rule that fails every day can keep a Fair health score (most of its checks pass) while failing every run. That's why the failed-run count sits beside the score on the validation's list row, the detail page charts failures per run, and why the dashboard's AI review is told which validations fail most runs.

When there's no score

• No runs in 30 days: nothing ran in the window. The badge reads No data and the caption says "No runs in 30 days". On a validation, the card also says when it last ran.
• No rules evaluated: runs happened, but every one errored before evaluating a rule (for example, the data source was unreachable). An errored run counts as a run but contributes no checks, so it can't drag a healthy score to zero.

Percentages are shown to the nearest whole percent. The pass rate is rounded down and the failure rate up, so one failure in a few hundred checks never reads as "100% passed". A share below 1% or above 99% keeps its decimal ("0.4% of checks failed").

How it's computed

The API computes the score when you read it, from the result each run recorded for each asset. Every result lists the checks it evaluated and whether each one passed; the number of checks and passes is recorded with the result when the run writes it, so reading a long window stays fast. Nothing is blended, so the number always reflects exactly the runs in the window. Workspace and team visibility apply as they do everywhere else: runs you can't see don't count.

Restricted assets: a restricted viewer can't read a restricted asset's own health (the asset list and the asset health endpoints hide it, like the asset itself). A validation's health and the dashboard headline are totals over their runs, so they still include the checks a validation ran on a restricted asset. That matches the validation results those viewers can already read (see Restricted assets).

A validation also keeps its latest run's own score (health_score on the validation, and health_score on each execution run). That's a single run's pass rate, useful for spotting the run that broke. The headline health is always the 30-day window.

Changed: earlier releases weighted checks by severity and blended each run's score 70/30 with the previous score. Both are retired. A run's stored score is now that run's own pass rate, and the headline is the plain 30-day pass rate. Scores stored by runs before this change keep their old values.

API

Field / endpoint	What it returns
window_health on GET /api/v2/.../validations and GET /api/v2/.../validations/{id}	{window_days, health_score, failure_rate, checks_evaluated, checks_passed, checks_failed, runs, runs_failed} over the validation's runs in the window (runs counts finished runs; a run still in progress isn't counted until it finishes). Pass ?window_days= (1–365, default 30) for another window; anything outside that range is a 422. health_score / failure_rate are null when nothing was evaluated.
GET /api/v2/organizations/{org_id}/workspaces/{ws_id}/health/data-assets?window_days=30	The same object plus data_asset_id, for every data asset with at least one run in the window. An asset that isn't listed had no runs in the window.
GET /api/v2/organizations/{org_id}/workspaces/{ws_id}/data-assets/{asset_id}/health?window_days=30	One asset. runs is 0 and the percentages are null when nothing ran. 404 if you can't see the asset.
health_score, failure_rate, checks_evaluated, checks_passed, checks_failed on GET .../dashboard/metrics?period=	The dashboard headline, over the selected period.
total_runs, by_status, by_group, group_by on GET .../dashboard/metrics?period=	The period's finished runs (one per run, never one per asset result), their pass / fail split, and the same runs by owning team (group_by: "team", with workspace_shared for runs of a validation with no team) or by workspace (group_by: "workspace", the org roll-up). The groups add up to total_runs, and the Reports summary counts runs the same way.

The data-asset endpoints need the can_view_results permission (the viewer role has it). See the API reference for the full surface.