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 isn't reported as failing anywhere, so its state is unknown. A run summary that counts only failures understates how much of the platform didn't 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's fixed, these findings go with it. The score doesn't count them, so one root cause isn't penalised twice.
What we need to check it
run_results.json from a dbt run or dbt build, alongside manifest.json.