Not exactly — and one quick clarification: in Prefect 3.x, the built-in flow hook is

on_failure

, not

on_error

. Difference: -

on_failure

fires when the flow ends in a FAILED state -

on_crashed

fires when the flow ends in a CRASHED state Those are different kinds of failures:

on_failure

- user-code exceptions - uncaught task/flow errors - timeouts / exhausted retries - generally: “your flow ran and failed”

on_crashed

- process/interruption/infrastructure-type failures -

SIGTERM

,

SIGKILL

,

KeyboardInterrupt

,

SystemExit

- worker/process/network issues outside normal user-code failure handling - generally: “the run was interrupted or the execution environment died” So if you're asking “does

on_crashed

behave the same way as

on_failure

?”, the answer is no — same hook style/signature, but different trigger conditions. Example:

python
from prefect import flow

def my_hook(flow, flow_run, state):
    print(flow.name, flow_run.id, state.name, state.message)

@flow(
    on_failure=[my_hook],
    on_crashed=[my_hook],
)
def my_flow():
    raise ValueError("boom")

This would trigger

on_failure

, not

on_crashed

. A couple caveats: - Hooks run client-side / in the execution environment, so

on_crashed

is inherently less guaranteed than server-side automation logic. - For worker-managed runs, crash handling can be owned by the runner/worker instead of the flow process itself. - If you need more reliable state-based notifications/actions, Automations are usually a better fit than hooks. If you want, I can also show you a state-by-state table for

on_completion

,

on_failure

,

on_cancellation

, and

on_crashed

.