Execution health · rule run-blocked-cascade
dbt models skipped behind a failure
A Metacenta review checks this under the rule A failure did not block the rest of the build. Everything below applies whether or not you ever commission one.
What this rule checks
From the results of your last dbt run or build, this rule flags each node that was skipped because something upstream failed. It names the failure that blocked it.
Why it matters
A skipped node is not reported as failing anywhere, so its state is unknown. A run summary that counts only failures understates how much of the platform did not execute.
How to fix it
Unblock the build — one failure is stopping the nodes behind it. Fix the upstream failure first. Every node skipped behind it, and everything under those, waits on that one fix.
When it is fine to leave
None, as long as the upstream failure is real. Once it is fixed, these findings go with it. The score does not count them, so one root cause is not penalised twice.
What we need to check it
run_results.json from a dbt run or dbt build, alongside manifest.json.