Great question. In Prefect 3.x,

run_count

increments each time the same flow run is (re)started after leaving a Running state — this can happen for reasons other than “retries,” like crash recovery, a manual resume/restart, infrastructure restarts, or a worker re-submission after a missed heartbeat. To find the exact reason for your run’s

run_count=2

, check the run’s state history, logs, and worker/infrastructure events around when it restarted. Here’s a fast way to investigate: 1) Inspect the flow run’s state history - This will show every state transition and the message that explains it (e.g., “crash detected,” “resumed by <user>,” etc.) - CLI:

prefect flow-run inspect 068e92c0-b816-796f-8000-58ea45be7220

- In the UI: open the flow run page → State history / Timeline Docs: - Flow run states API 2) Review the flow run logs - Look for a second “Starting flow run...” line or messages like “Resubmitting after crash,” “Lost heartbeat,” “Infrastructure exited,” or “Resumed by …” - CLI:

prefect flow-run logs 068e92c0-b816-796f-8000-58ea45be7220 --reverse

3) Check worker logs (most telling for crash recovery/resubmission) - Identify the worker handling your pool/queue (

work_pool_name='analysis-pool'

,

work_queue_name='default'

) - On that worker’s host/cluster logs, grep the run id:

# Example on the worker host
grep 068e92c0-b816-796f-8000-58ea45be7220 /path/to/worker/logs/*

- Look for messages indicating re-attachment/resubmission, infrastructure restarts, or missed heartbeats. 4) Check events/timeline - In the UI timeline, look for events like “Worker claimed,” “Infrastructure started,” “Run crashed,” “Resubmitted,” “Resumed by <user>” - CLI stream (you can filter with grep):

prefect events stream --format text | grep 068e92c0-b816-796f-8000-58ea45be7220

5) Optional: Query via Python to dump states and logs with messages

from prefect.client.orchestration import get_client
from prefect.client.schemas.filters import LogFilter, LogFilterFlowRunId
from prefect.client.schemas.sorting import LogSort

flow_run_id = "068e92c0-b816-796f-8000-58ea45be7220"

async def debug():
    async with get_client() as client:
        fr = await client.read_flow_run(flow_run_id)
        print("run_count:", fr.run_count, "infrastructure_pid:", fr.infrastructure_pid)

        states = await client.read_flow_run_states(flow_run_id)
        for s in states:
            print(s.timestamp, s.name, s.type, "|", s.message or "")

        logs = await client.read_logs(
            LogFilter(flow_run_id=LogFilterFlowRunId(any_=[flow_run_id])),
            limit=2000, sort=LogSort.TIMESTAMP_ASC
        )
        for log in logs:
            print(log.timestamp, log.level, log.message)

How to interpret what you find - Running → Crashed → Scheduled/AwaitingRun → Running - Infrastructure or process crash/restart; worker likely resubmitted. Check worker logs and your infra (e.g., container/pod restarts). - Running → Paused → Running - Manual resume or automation resume; the message usually says who/what resumed it. - Running → Cancelling/Cancelled → Running - A manual restart (UI/CLI) of the same run. - Running → AwaitingRetry → Running - Would indicate an internal retry; not your case since

retries=0

. - Running → NotReady/MissingConcurrency → Running - Resumed after a concurrency gate; depending on conditions, this can increment

run_count

. The state message will indicate waiting for a slot. A few notes on your snippet - The

idempotency_key

you see ties the run to its schedule slot; it doesn’t cause new runs, and it won’t explain

run_count

. -

infrastructure_pid

changes can indicate a restart; you can often infer a restart if the pid in earlier logs differs from the current one. If you want, paste the output of: -

prefect flow-run inspect 068e92c0-b816-796f-8000-58ea45be7220

-

prefect flow-run logs 068e92c0-b816-796f-8000-58ea45be7220 --tail

and I can help pinpoint the exact transition that bumped

run_count

to 2.