Thanks for reaching out — that message is a generic wrapper Prefect shows when the “submission” step fails. In Prefect 3.x, “submission” is when a worker tries to launch the infrastructure for your flow run (local process, Docker container, Kubernetes Job, ECS task, etc.). When that step errors (e.g., image can’t be pulled, missing permissions, source checkout fails), the flow run is marked Failed with “Flow run failed during submission.” Where to find the real error - Flow run page → Logs: look for the first error just before the generic message; it often names the failing system (Docker, Kubernetes, Git, etc.). - Worker logs: the submitting worker typically logs the underlying exception (e.g., registry auth error, K8s RBAC, missing file, etc.). - Work pool health: ensure there’s at least one healthy worker online for the pool and that concurrency limits aren’t blocking new runs. Common root causes to check - Docker work pool - Image doesn’t exist or can’t be pulled (private registry without creds, wrong tag, rate limits). - Flow code isn’t in the image and there’s no source checkout configured, leading to import errors at startup. - Kubernetes work pool - Insufficient RBAC to create Jobs, wrong namespace, missing imagePullSecret, or node constraints. - Source checkout (flow.from_source) - Repo URL or ref invalid; token missing or lacks scope; worker can’t reach the repo/network. - Local process - Entrypoint path incorrect on the worker machine; missing dependencies; environment variables not set. - Prefect connectivity and version - Worker cannot reach Prefect Cloud/Server (network/firewall), expired API key, or significantly mismatched versions between server and worker. If you can share a bit more, I’ll pinpoint this quickly: - Are you on Prefect Cloud or self-hosted? - Work pool type (local process, Docker, Kubernetes, etc.) and where the worker is running - A copy of the first error line(s) from the flow run logs and the worker logs around the failure - How the deployment is defined: - Using flow.from_source(...)? Repo URL/branch and whether it needs auth - If using containers: the image name/tag and where it’s hosted - Any special env vars or secrets required at runtime Quick next steps to try - Re-open the failed flow run and copy the earliest ERROR/TRACE lines (before “failed during submission”). - Check the submitting worker’s logs from the same timestamp. - If possible, set PREFECT_LOGGING_LEVEL=DEBUG on the worker and retry to get more detail. - If using containers, verify the image exists and is accessible from where the worker runs. - If using source checkout, verify the repo URL, ref/branch, and credentials. Paste the logs here and details on your pool/worker setup and I’ll help interpret the exact failure and the fix.

@Marvin I'm using Prefect Cloud and prefect3.x but how can i checking work pool type and where the worker is runiing

Great — since you’re on Prefect Cloud and 3.x, here’s how to check both the work pool type and where your worker is running. How to check your work pool type 1) In the Cloud UI - Go to Work Pools in your workspace - Find your pool and open it - The pool’s Type will be shown on the Overview (e.g., Process, Docker, Kubernetes, ECS, etc.) - You can also see Work Queues and any Workers currently online 2) Via CLI - List pools (add -v to see more detail in the table):

prefect work-pool ls -v

- Inspect one pool to see full details including its type and base job template:

prefect work-pool inspect "YOUR_POOL_NAME"

How to see where the worker is running - Conceptually, a worker runs wherever you started the process/container that executed:

prefect worker start -p YOUR_POOL_NAME

- In the Cloud UI: open the Work Pool → Workers tab. You’ll see each worker’s Name, Status, Last heartbeat, Version, and Platform (OS/arch). This tells you what kind of machine it’s on, but not the exact host if you didn’t name it. - Best practice: name workers to indicate their host or environment so it’s obvious where they live:

prefect worker start -p YOUR_POOL_NAME -n "$(hostname)-docker"

Where to find the actual machine/process - If you ran it in a terminal or VM: it’s on that host (check your shell/process manager like systemd, PM2, Supervisor, etc.). - If you containerized it with Docker: check the host running Docker and look for the container that starts with “prefect worker start…”. - If you run it in Kubernetes: check the cluster/namespace where you created the Deployment/Pod that runs the worker container. - If you run it in ECS: check the ECS service/task that runs your worker container. Tip: Worker logs are local to where the worker runs (not collected by Cloud), so to diagnose “submission” errors you’ll usually: - Check the flow run’s logs in Cloud for the first ERROR before “failed during submission” - Then check the worker’s local logs on the machine/container where it’s running If you share your work pool name and how you started the worker (VM, Docker, K8s, ECS), I can give exact steps to find it and confirm the type.

Thanks — that message means your account has reached the quota for “managed work pools” on your current Prefect Cloud plan. A managed work pool uses Prefect’s Serverless (Prefect-managed) infrastructure. On the free/Hobby plan, there’s a low cap on how many managed pools you can create, and you cannot create push/hybrid pools. About Starter limits - Upgrading to Starter unlocks push/hybrid work pools (so you can run on your own infrastructure with workers) and increases limits compared to Hobby. - However, Prefect does not publicly list an exact number for “managed work pools” per plan. The precise limits may vary and are shown in-app on your billing/plan page or can be confirmed by our team. Where to check and next steps - In the Cloud UI: go to your workspace, then Settings → Plan/Billing to view your current usage and limits. - Pricing and plan features overview: Prefect Cloud pricing - Work pools concept (managed vs push/hybrid): Work pools in Prefect 3.x - If you want exact quota details before upgrading, please reach out via the in-app chat or contact Prefect and we’ll confirm the current limits for your account. Ways to proceed right now - Reuse one managed pool with multiple work queues instead of creating more pools (queues give you separation and concurrency controls within a single pool). - Delete unused managed pools to free up the quota:

prefect work-pool ls -v
prefect work-pool delete "POOL_NAME"

- Upgrade to Starter and use push/hybrid work pools to run on your own infrastructure (this avoids the “managed pool” cap entirely and is what most teams do for production). If you share which plan you’re on now and how many managed pools you need, I can suggest the cleanest consolidation (e.g., moving to queues) or help validate the upgrade path.