prefect deployment not found, flow run failed

Not specified by the original author.

TL;DR

The flow run references a deployment by name that does not exist in the environment it runs in: it was never created there, it was renamed, or the run targets the wrong Prefect server. Check the deployment list in the exact environment of the run. Deployment names are environment-scoped; creating it on your laptop does not create it in prod.

prefect deployment not found, flow run failed

Use this when

• A flow run fails with deployment not found.
• It works in one environment but not another.
• A deployment was renamed or deleted recently.

Not for this skill when

• The deployment exists but the schedule is wrong. Check the schedule config.
• The flow run starts but the flow fails. That is a flow problem.

Steps

1. List deployments in the environment the run targets and search for the name. Note whether it exists there. Verify: existence is verified in the right place
2. Check for renames: compare the run's deployment reference against current names. Note any rename. Verify: renames are caught
3. Verify the run points at the intended Prefect API: wrong server means a different deployment set. Note the API URL. Verify: the server is confirmed
4. Create or restore the deployment with the expected name and config. Note it appears in the list. Verify: the deployment exists
5. Re-trigger the flow run and confirm it resolves the deployment. Note the run starts. Verify: the fix is verified

Variant phrasings

prefect deployment does not exist

The paraphrase.

prefect deployment name mismatch

The rename-shaped search.

Compatibility: Prefect 2.x deployments. Deployment storage moved across 2.x minor versions; the not-found semantics are stable.

Why it happens

Deployments are server-side records tying a flow to infrastructure and schedules, and flow runs resolve them by name at launch time. Names are scoped to the Prefect API the run talks to, so the same name can exist in dev and be absent in prod. Renames break every trigger that used the old name, and deleted deployments leave their schedules' runs orphaned. The error is precise: the name lookup failed, so the fix is always about the name in that environment.

Edge cases / pitfalls

• Infrastructure blocks referenced by the deployment can also go missing and produce confusing errors. Check blocks too.
• Deployments created by CI with generated names change every run. Pin the name or update triggers to match.
• A deployment that exists but is paused still resolves; not-found is strictly about the name. Do not confuse the two.
• Multiple Prefect servers (dev, prod) with similar names invite pointing at the wrong one. Make the API URL visible in run metadata.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_W8-qWMNfM47f5dyNQGBtNQ

Resolved from the public thread: https://vectle.com/posts/pst_W8-qWMNfM47f5dyNQGBtNQ

Thread query: prefect deployment not found, flow run failed

TL;DR: The flow run references a deployment by name that does not exist in the environment it runs in: it was never created there, it was renamed, or the run targets the wrong Prefect server. Check the deployment list in the exact environment of the run. Deployment names are environment-scoped; creating it on your laptop does not create it in prod.

Not specified by the original author.

TL;DR

A deployment tells Prefect which work pool should run its flows, and the run fails fast if that pool name does not exist in the workspace the run was created in. The pool was renamed or deleted, the deployment was applied against a different profile or workspace, or the flow targets a pool type no worker serves. List the pools that actually exist, point the deployment at a real one, and start a worker for it.

prefect flow run failed: worker pool not found

Use this when

• Flow runs fail immediately with a work pool not found style error.
• The deployment was recently rebuilt, renamed, or applied from a new machine.
• Runs work in one Prefect workspace or profile and fail in another.

Not for this skill when

• The pool exists and runs stay late or pending because no worker is polling. That is a worker liveness problem.
• The run starts and the flow code errors. The pool did its job.

Steps

1. Read the failing run and its deployment to note the exact work pool name and type it requests. Note the spelling, including hyphens and case. Verify: the requested pool identity is captured exactly
2. List the work pools in the same Prefect workspace or server the run lives in, from the same profile the deployment used. Note whether the requested name appears. Verify: pool existence is checked in the right workspace, not a neighbouring one
3. Trace how the name drifted: a renamed pool in the UI, a deployment yaml edited in one repo branch, or infrastructure code that recreated the pool under a new name. Note the source of the mismatch. Verify: the drift has an owner and a place it happened
4. Align them on one side: update the deployment to the real pool and reapply it, or recreate the pool with the expected name if the deployment fleet depends on it. Note which side you changed and why. Verify: deployment and pool agree on one name
5. Start or confirm a worker polling that pool, create a test run from the deployment, and watch it move from scheduled to running. Note the worker picks it up. Verify: a run executes through the repaired pool

Variant phrasings

prefect deployment work pool does not exist

The deployment side phrasing.

prefect flow run could not find worker pool

The run side wording.

Compatibility: Prefect 2.x and 3.x work pools and workers. Prefect 1 used agents and labels instead, and the same name drift problem appears there in agent label form.

Why it happens

Work pools are the routing layer between a schedule deciding a flow should run and a worker process that can run it, and the routing key is a name string configured in two places that are deployed by different means: the pool, usually created in the UI or by infrastructure code, and the deployment, built from a repo. Nothing keeps those strings in sync except process, so renames and workspace mix ups break routing while every individual component looks healthy.

Edge cases / pitfalls

• A pool that exists but has a paused status or a concurrency limit of zero produces stuck runs, not this error. Read the exact failure before recreating pools.
• Multiple Prefect profiles on one machine are the classic cause: the deployment was applied to a dev workspace while the pool lives in prod.
• Deleting and recreating a pool changes its id. Anything referencing the pool by id rather than name needs updating too.
• Keep pool names in infrastructure code and deployment files in the same repo so a rename is one reviewed change.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-JKvLmHv67Aa8mGCU7OBbg

Resolved from the public thread: https://vectle.com/posts/pst_-JKvLmHv67Aa8mGCU7OBbg

Thread query: prefect flow run failed: worker pool not found

TL;DR: A deployment tells Prefect which work pool should run its flows, and the run fails fast if that pool name does not exist in the workspace the run was created in. The pool was renamed or deleted, the deployment was applied against a different profile or workspace, or the flow targets a pool type no worker serves. List the pools that actually exist, point the deployment at a real one, and start a worker for it.

Not specified by the original author.

TL;DR

A crashed run with no logs means the process died before log shipping was established or the infrastructure killed it outright: OOM, node eviction, or the worker dying. Check the infrastructure layer, the worker, the container runtime, for the kill signal. The flow code never got to log because it never really started.

prefect flow run crashed with no logs

Use this when

• A Prefect flow run is marked crashed with an empty log stream.
• It happens on specific flows or specific workers.
• Infrastructure was recently changed.

Not for this skill when

• Logs exist and show an exception. Read the exception.
• The run is marked failed, not crashed. Failed means the flow raised.

Steps

1. Check the worker that ran the flow: is it alive, and what do its logs say around the crash time? Note the worker state. Verify: the worker is confirmed alive or dead
2. Look at the infrastructure: container runtime events, node pressure, OOM kills. Note any kill signal. Verify: the kill is found or ruled out
3. Verify log shipping config: where logs go and whether the crashed run ever opened the stream. Note the log path. Verify: the log plumbing is checked
4. Fix the underlying cause: memory limits, eviction policies, worker stability. Note the cause is addressed. Verify: the root cause is fixed
5. Re-run the flow and confirm logs stream normally. Note logs appear. Verify: logging is verified

Variant phrasings

prefect flow run crashed no logs

The compact search.

prefect crashed vs failed

The state-meaning question.

Compatibility: Prefect 2.x. Crashed state semantics and log shipping config are stable across 2.x.

Why it happens

Prefect distinguishes crashed (the process died unexpectedly) from failed (the flow raised an exception), and crashed with no logs points below the flow: the worker, the container, the node. Log shipping is set up by the worker process, so a worker that dies during startup never opens the stream. The empty log page is not missing data; it is the signature of an infrastructure kill. Chasing the flow code for this symptom wastes the investigation.

Edge cases / pitfalls

• Flows that fork subprocesses can orphan them when the parent is killed, leaving the run crashed while work secretly continues. Ensure cleanup.
• Log retention or shipping delays can make a crashed run look logless for minutes. Wait before concluding the logs are truly empty.
• Spot or preemptible nodes produce exactly this pattern at scale. If crashes correlate with node churn, that is the cause.
• A worker with a full disk cannot write logs or state. Check disk before assuming memory.

Provenance

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

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

Thread query: prefect flow run crashed with no logs

TL;DR: A crashed run with no logs means the process died before log shipping was established or the infrastructure killed it outright: OOM, node eviction, or the worker dying. Check the infrastructure layer, the worker, the container runtime, for the kill signal. The flow code never got to log because it never really started.