# Checkpoints Example
URL: /examples/checkpoints

The upstream checkpoints.py example — a failing measurement, a checkpoint, and a long burn-in phase that is skipped because of it, with ConsoleSummary showing the failure.

By default a failed measurement does not stop a test. A checkpoint does. Based on `examples/checkpoints.py`, with the phases it imported from `measurements.py` inlined.

The test returns in well under a second: `lots_of_measurements` still ran (a failed measurement is not terminal), the checkpoint saw `failing_phase`'s `FAIL` and returned `STOP`, and the 100-second `long_running_phase` never started.

Shorthand for `PhaseFailureCheckpoint.all_previous(name)`: stop if any earlier phase in the test has outcome `FAIL`. Checkpoint types →

Put the checkpoint immediately before the expensive phase. Everything before it still runs, so you collect all cheap failures in one pass.

Lists every failed measurement with value and validator, which the one-line banner does not. Console summary →

A checkpoint is not a phase: it leaves no phase record, and 1.6.1 does not serialize `TestRecord.checkpoints` to JSON. The effect is visible as the missing `long_running_phase` and the `FAIL` outcome. JSON format →

Stop on the very first failed measurement anywhere: `test.configure(stop_on_first_failure=True)` — example.

Only check the immediately preceding phase: `PhaseFailureCheckpoint.last('after_cal')`.

Inside a subtest, pass `action=htf.PhaseResult.FAIL_SUBTEST` to fail only that subtest instead of stopping the test.

Trigger on a diagnosis rather than a failure: `htf.DiagnosisCheckpoint(name, DiagnosisCondition.on_any(...))`.

<Card title="Checkpoints & Branching" href="/checkpoints" description="All checkpoint and condition types." />

<Card title="Stop on first failure" href="/examples/stop-on-first-failure" description="The blunt alternative." />