It’s likely Prefect’s worker prefetch window. By default, workers “look ahead” 10 seconds for scheduled runs, so a run for 120500 can be picked up at 120459 (or earlier), causing “same-minute” overlap. Two ways to fix it: 1) Minimize or disable prefetch so runs don’t start early - Set the worker’s prefetch window to 0–1 seconds:

# env vars
export PREFECT_WORKER_PREFETCH_SECONDS=0
export PREFECT_WORKER_QUERY_SECONDS=5  # optional: poll a bit more frequently

# or via CLI when starting the worker
prefect worker start --pool <your-pool> --prefetch-seconds 0

Notes: - With prefetch=0, the run will be picked up on or just after the scheduled minute (not before). If your poll interval is 10s, expect up to ~10s of delay; setting

PREFECT_WORKER_QUERY_SECONDS

to 3–5s reduces that. 2) Prevent overlaps regardless of timing with a deployment-level concurrency limit - Ensure only one run can be active at a time; queue the next if the previous is still running:

python
from prefect import flow
from prefect.client.schemas.objects import ConcurrencyLimitStrategy

@flow
def my_flow():
    ...

my_flow.deploy(
    name="minute-job",
    work_pool_name="your-pool",
    concurrency_limit=1,
    concurrency_options={"collision_strategy": ConcurrencyLimitStrategy.ENQUEUE},
)

- This guarantees no overlap even if a run starts a second early; the next one will wait for a free slot. If you can share whether you’re running via a worker or

flow.serve()

(runner), I can tailor the exact knobs; the same idea applies, but the settings are set slightly differently.