Great question. Assuming Prefect 3.x: - The retry “attempt” counter (StateDetails.run_count) is incremented when the next attempt actually starts — i.e., when the run enters Running. Merely transitioning to AwaitingRetry (e.g., from Failed → AwaitingRetry) does not increment it. - Practically: Failed → AwaitingRetry → Scheduled → Running. The increment happens on that final step (when the new attempt begins). Manual retries: - Manually triggering a retry (UI/API) schedules another attempt. When that attempt starts (enters Running), run_count increments — so it does count against the max_retries budget used by the orchestrator to decide whether to auto-retry again. - You can still manually retry even after max_retries are exhausted; however, automatic retries will no longer be scheduled by the policy once the limit is reached. References: - States in Prefect 3 - Retries how-to

Short answer: No. Moving Pending → AwaitingRetry does not increment anything by itself. The counter increments only when the run actually starts again (i.e., when it enters Running). A few nuances in Prefect 3.x: - Attempt/run count increments on entry to Running, not on entry to AwaitingRetry. - Forcing Pending → AwaitingRetry before the first run won’t “consume” a retry budget; when it eventually starts, that will be attempt 1. - If you force AwaitingRetry after a failure, the next start will be the next attempt number. Whether Prefect will auto-schedule yet another retry after a subsequent failure depends on how many failures/attempts have already occurred relative to max_retries. Refs: - States: https://docs-3.prefect.io/v3/concepts/states - Retries: https://docs-3.prefect.io/v3/how-to-guides/workflows/retries