Short answer: pause/clear the schedule first, then delete the currently scheduled runs. In Prefect 3.x, if you just delete scheduled runs while the deployment schedule is still active, the scheduler may recreate them. Do this: 1) Stop future runs from being created - Pause the schedule (keeps it but stops generation):

prefect deployment schedule pause <flow-name>/<deployment-name>

- Or clear all schedules from the deployment (removes them):

prefect deployment schedule clear <flow-name>/<deployment-name> -y

2) Delete all existing SCHEDULED runs for that deployment (small script)

import asyncio
from prefect.client.orchestration import get_client
from prefect.client.schemas.filters import (
    FlowRunFilter,
    FlowRunFilterDeploymentId,
    FlowRunFilterStateType,
)
from prefect.client.schemas.objects import StateType

DEPLOYMENT = "my-flow/my-deployment"  # replace with your flow/deployment name

async def main():
    async with get_client() as client:
        dep = await client.read_deployment_by_name(DEPLOYMENT)

        # page through scheduled runs if you have many; this fetches up to 1000 at a time
        while True:
            runs = await client.read_flow_runs(
                flow_runs_filter=FlowRunFilter(
                    deployment_id=FlowRunFilterDeploymentId(any_=[dep.id]),
                    state_type=FlowRunFilterStateType(any_=[StateType.SCHEDULED]),
                ),
                limit=1000,
            )
            if not runs:
                break
            for r in runs:
                await client.delete_flow_run(r.id)
            # loop continues until no more scheduled runs remain

asyncio.run(main())

Notes: - Use the full name format

<flow-name>/<deployment-name>

for the CLI commands. - If you only want to prevent new runs (and don’t care about already-scheduled ones), pausing or clearing the schedule is sufficient. Would you like me to adapt the script to your deployment name and run it against a large number of runs with pagination/backoff?

Short answer: there isn’t a single built-in command to pause all deployments at once. Options you have: - Quick global stop (execution only): pause your work pools. This will stop workers from picking up runs, but it won’t stop the scheduler from creating future SCHEDULED runs.

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

Repeat for each pool you use. - Pause all deployment schedules via a small script (stops new runs from being generated):

import asyncio
from prefect.client.orchestration import get_client

async def pause_all_schedules():
    async with get_client() as client:
        offset = 0
        page_size = 200
        while True:
            deployments = await client.read_deployments(limit=page_size, offset=offset)
            if not deployments:
                break
            for dep in deployments:
                schedules = await client.read_deployment_schedules(dep.id)
                for sch in schedules:
                    await client.pause_deployment_schedule(sch.id)
                    print(f"Paused schedule {sch.id} for deployment {dep.name}")
            offset += page_size

asyncio.run(pause_all_schedules())

If you want, I can adapt that script to target specific work pools, tags, or only active schedules.

Got it — let’s get this working. In Prefect 3.x, a work pool concurrency limit caps the number of RUNNING flow runs across that pool. If it looks like “nothing runs” after you set a limit, it’s usually one of these: Quick checks 1) The pool isn’t paused and the limit > 0 - Inspect:

prefect work-pool inspect <pool-name>

- If needed:

prefect work-pool set-concurrency-limit <pool-name> 2

- To clear and reapply:

prefect work-pool clear-concurrency-limit <pool-name>
prefect work-pool set-concurrency-limit <pool-name> 2

2) A worker is running and polling the right queues - Start or restart a worker and ensure it points to the correct pool/queues:

prefect worker start -p <pool-name> -q <queue-name>

- If you don’t pass

-q

, it will default to the pool’s default queue. Make sure your deployments are targeting the same queue(s). 3) No work queue is paused or hard-limited to 0 - Check:

prefect work-queue ls -p <pool-name> -v

- If you see a queue concurrency limit of 0, clear or raise it:

prefect work-queue clear-concurrency-limit <queue-id-or-name>
# or
prefect work-queue set-concurrency-limit <queue-id-or-name> 2

4) There are actually runs to adopt - Preview what the worker should see:

prefect work-queue preview -p <pool-name>

5) No tag-based (task-level) concurrency limits are blocking progress - List and inspect:

prefect concurrency-limit ls
prefect concurrency-limit inspect <tag>

- If a tag is limiting tasks to 0 or has stuck slots, reset it:

prefect concurrency-limit reset <tag>

If you still see no adoption after setting the pool limit to something > 0, please share: - The output of

prefect work-pool inspect <pool-name>

-

prefect work-queue ls -p <pool-name> -v

- The exact

prefect worker start ...

command you’re using - Any worker log lines like “concurrency limit reached” or “no eligible runs” I can help pinpoint the culprit with that info, or I can provide a quick script to verify/run a controlled test (e.g., set pool limit=1 and launch a few test runs to confirm they serialize).