## TL;DR
An asset check with severity ERROR and blocking enabled is designed to stop the line: when it fails, Dagster marks the materialization run failed and blocks downstream assets from building on bad data. Read the check result to see what actually failed, decide whether the data or the check is wrong, and fix that side. Downgrading severity or turning off blocking makes the pipeline green by removing the guardrail, so only do it as a recorded, temporary decision.

```text
dagster asset materialization failed: check severity error blocking
```

## Use this when
- A run fails at an asset check and downstream assets never materialize.
- The check result shows error severity and a blocking failure in the event log.
- The same check passed until a source change or a threshold edit.

## Not for this skill when
- The check has warn severity and the run failed elsewhere. Keep looking at the run events.
- The asset code itself raised before any check ran. That is a materialization bug, not a check block.

## Steps
1. Open the run and the asset check evaluation in Dagster and note the check name, its severity, whether blocking is on, and the metadata it reported, such as the failing row count. Note the measured value, not just the failure. Verify: the check verdict is understood in numbers
2. Reproduce the check condition against the materialized data with a query: count the rows or values the check rejects. Note whether the data really violates the rule. Verify: data fault versus check fault is decided with evidence
3. If the data is wrong, trace it to the upstream asset or source and fix or reload that, rather than editing the check. Note the upstream correction. Verify: the cause upstream is addressed
4. If the check is wrong, for example a threshold written for another table or a null rule that ignores a legitimate state, correct the check logic and add the legitimate case to its tests. Note the check change. Verify: the guardrail now matches the real contract
5. Rerun the asset and its check, confirm the check passes and downstream assets materialize in the same run plan. Note the downstream asset events appear. Verify: the line moves end to end with the guardrail intact

## Variant phrasings
### dagster blocking asset check failed downstream not materializing
The downstream symptom phrasing.
### dagster AssetCheckSeverity ERROR blocks materialization
The severity setting searched directly.

Compatibility: Dagster 1.x asset checks with severity and blocking support. Older Dagster versions used different quality mechanisms; the blocking behaviour described is the asset checks feature.

## Why it happens
Asset checks are a contract enforcement point, and blocking error checks turn a data quality signal into a hard dependency. That is the feature working, which is why the failure feels abrupt: pipelines that used to limp forward on bad data now stop, visibly, at the check. The two honest causes are bad data arriving from upstream and a check written against an assumption that aged out, such as a volume threshold from a smaller era of the table. Everything else is ways of muting the alarm.

## Edge cases / pitfalls
- A check that reads the asset before the materialization commits can race and fail on partial data. Confirm the check targets the finished asset output.
- Blocking checks in a partitioned asset block per partition. One bad partition should not freeze the rest if your run config separates them.
- Record any temporary severity downgrade as an incident action with an owner and a restore date, or it becomes permanent by default.
- Checks that call external systems can fail on the call, not the data. The evaluation metadata should separate a check error from a check failure.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_22SWHxaV9aKv6KQgzTIMbg