Most likely:

NOT READY

does not mean “this deployment cannot run”. In Prefect 3, deployment readiness is mainly a health signal tied to whether a worker/work queue has been recently polled, not whether you can manually trigger the deployment. Why this happens - A deployment can still be started manually and run fine. - But if Prefect Server does not see recent polling activity for that deployment’s work queue, it may mark the deployment as

NOT READY

. - This is especially common on self-hosted setups where: - no worker is currently running - the worker is running but not polling the correct pool/queue - polling is intermittent - the deployment was created/updated, but no worker has checked in recently In practice,

NOT READY

often means: “Prefect doesn’t currently observe active worker polling for this deployment,” not “the deployment is broken.” Common causes 1. No active worker for that deployment’s work pool 2. Worker is attached to the wrong work pool or queue 3. Worker briefly went offline 4. Self-hosted server services are lagging/misconfigured 5. The flow is being started in a way that bypasses normal worker polling, so runs work even though readiness stays

NOT READY

What to check 1. Which work pool / queue the deployment uses 2. Whether a worker is running for that pool 3. Whether the worker is polling continuously 4. Server logs for worker/foreman/readiness updates Useful checks in the UI / API - Open the deployment and verify its work pool and work queue - Check that a worker is connected to that same pool - Check whether the worker shows as online - Compare with one of your other “READY” deployments that uses the “same pipeline” Important distinction - Deployment READY/NOT READY = health/readiness indicator - Ability to launch a run = separate thing So the behavior you described is possible and usually points to worker polling / queue readiness, not to a bad deployment definition. What I’d verify first - Is the deployment assigned to the exact same work pool as the working one? - Is there an active worker polling that pool? - If you have multiple queues, is it polling the correct queue too? If you want, I can help you narrow it down quickly if you share: - how you deployed it (

prefect deploy

, Python

.deploy()

,

serve()

, etc.) - the deployment’s work pool / work queue - how you are starting your worker - whether this is manual trigger only or also scheduled runs are succeeding Relevant docs: - Workers and work pools - Deployments in Prefect 3 - Self-hosting Prefect

If everything is truly the same, then the most likely explanation is:

READY

/

NOT READY

is based on observed polling state for that specific deployment record, and it can get out of sync or lag behind actual runability. So yes — two deployments in the same pool, same queue, same worker setup can temporarily show different readiness states even though both can run. What this usually means in your case Since: - same work pool - same work queue - same workers - same deployment pipeline - and the flow runs successfully then this is probably not an infrastructure problem. It’s more likely one of these: 1. Stale readiness metadata on that deployment - the deployment record’s readiness fields/status did not refresh as expected - recreating or updating the deployment may clear it 2. Timing / polling race - Prefect’s readiness status is derived from recent polling windows - one deployment may be marked

NOT READY

while another is

READY

simply because of when status evaluation happened 3. UI/API status inconsistency - the UI may show a cached or lagging status - especially on self-hosted setups, background services can update these states asynchronously 4. A deployment-specific metadata difference not obvious in the pipeline - even if your pipeline is the same, the resulting deployment object may differ: - different deployment ID - different inferred entrypoint/source metadata - schedule state differences - old deployment record reused instead of replaced Important point: If the deployment can be started and the worker picks it up successfully, then the

NOT READY

label is usually informational noise, not an execution blocker. Things worth checking next 1. Inspect the deployment record details Compare the broken one vs a READY one: - deployment ID - creation/update time - work pool name - work queue name - paused state - schedule attached or not 2. Redeploy with a forced update If possible, update the deployment again or delete/recreate it. If the status flips to

READY

, that strongly suggests stale metadata. 3. Check self-hosted server background services On self-hosted Prefect Server, readiness transitions depend on server-side services running correctly. If those are delayed or unhealthy, status can drift from reality. 4. Check if this is only UI-deep Trigger runs from the API/UI and confirm: - do scheduled runs enqueue? - does the worker pick them up? - do they complete normally? If yes, I would treat this as a status/reporting issue, not a deployment issue. Most likely conclusion from what you described Because the deployment runs fine and shares identical infrastructure with deployments that show

READY

, the

NOT READY

state is most likely: - stale readiness state - delayed background status update - or a self-hosted UI/server inconsistency If you want, I can help you do a side-by-side checklist of the exact deployment fields to compare between the

READY

and

NOT READY

deployments. That should isolate whether this is just cosmetic or a real metadata mismatch.