Sorry, I encountered an error while processing your request. Please try again.

Yes. In Prefect 3.x, webhook-triggered runs still go through the same orchestration path as any other trigger, so a deployment’s concurrency limit is enforced. - If the limit is reached and the collision strategy is ENQUEUE (default), the run enters the AwaitingConcurrencySlot state and waits for a slot. - If the collision strategy is CANCEL_NEW, the new run is canceled. Docs for reference: - Deployments (concurrency limiting) - States (AwaitingConcurrencySlot) - Webhooks (how webhooks trigger automations/actions) If you’re seeing behavior that doesn’t match this, share your Prefect version and how the webhook/automation is configured and I’ll help dig in.

Got it — when you say “enqueued” on 3.6.13 but “instantly executes” on 3.4.24, that usually means the run is either: - Pending (no worker picked it up), or - AwaitingConcurrencySlot (deployment/pool concurrency is full) In Prefect 3.x the UI may label this as “Enqueued”, but the actual state name on the flow run will be Pending or AwaitingConcurrencySlot. Quick checks - On the flow run page, look at the exact state name: - If it’s AwaitingConcurrencySlot, your deployment (or work pool) concurrency limit is reached. Increase the limit or wait for slots to free up. See Concurrency. - If it’s Pending, ensure a worker is polling the right work pool/queue and the pool is READY (not PAUSED). See Work pools & workers. - Make sure the worker version is healthy and polling the correct pool type. 3.6.x includes stricter/fixed concurrency handling, so a run that previously “slipped through” on 3.4.x may now correctly wait for a slot. CLI to diagnose - Inspect the deployment (check concurrency limit, work pool, and work queue):

prefect deployment inspect "<flow_name>/<deployment_name>"

- Check pool status and concurrency:

prefect work-pool ls
prefect work-pool inspect <pool-name>

- Inspect a stuck flow run:

prefect flow-run inspect <flow_run_id>

- If needed, start a worker with debug logs to confirm it’s polling and what it’s seeing:

prefect worker start -p <pool-name> --name debug --log-level DEBUG

A few targeted questions to pinpoint the cause - What exact state is shown on the flow run (Pending vs AwaitingConcurrencySlot)? - Does the deployment have a concurrency limit set? Does the work pool have a concurrency limit? - Is the work pool READY and not PAUSED? Do you see a worker polling it in the last 60s? - Which work pool type and worker type are you using (e.g., Process, Docker, Kubernetes)? - Are the server/worker versions mixed (e.g., server 3.6.x with a 3.4.x worker), or all on 3.6.13? If you share the deployment name, pool name/type, and the flow run state detail, I can help interpret and suggest the fix. Helpful docs: - States: https://docs.prefect.io/latest/concepts/states/ - Work pools & workers: https://docs.prefect.io/latest/concepts/work-pools/ - Concurrency: https://docs.prefect.io/latest/concepts/concurrency/

Sorry, I encountered an error while processing your request. Please try again.