Short answer: don’t assume it will “clear” on its own. If the flow run is truly in

Crashed

, that is generally a terminal state in Prefect — it does not usually revert back to

Running

just because a child task/subflow is still working. What you’re seeing usually means one of these happened: * the parent flow process died / lost infrastructure / got killed * but a child task or subflow still has its own state stuck in

Running

, or is actually still executing somewhere * Prefect does not automatically reconcile every child state back from a crashed parent So this is not something I’d treat as “just 35 million rows, wait longer and it’ll fix itself.” What I’d check next: 1. Open the crashed flow run’s state message Look for text like: *

exited with non-zero status code

*

SIGTERM

*

SIGKILL

*

OOM

* timeout-related wording That message is the best clue for whether this was: * a timeout * out-of-memory / container kill * worker/infrastructure failure 2. Check the worker / infrastructure logs Especially if this is running in Docker, Kubernetes, ECS, etc. If it was killed for memory, you’ll often see exit codes like

137

/

SIGKILL

. 3. Check whether the “running” task/subflow is actually producing logs If logs are still advancing, it may genuinely still be working. If logs stopped a while ago, it may just be stuck in

Running

. About timeouts: * A long-running load like 35 million rows can require increasing timeouts * But

Crashed

is not automatically the same thing as “Prefect got tired of waiting” * Task timeouts usually produce task failure behavior * Flow/infrastructure timeouts often show up as the process being terminated, which can lead to

Crashed

So: yes, timeout is possible, but I would confirm from the crash message/logs before increasing it. Given your snippet:

Jobs: 0/2 (0.0%) | Time: 17.52s | Rate: 0.00/s
Memory usage: 517.81 MB (70.20%) | CPU usage: 0.00%

that suggests the process may be idle / waiting, not actively loading rows at that moment. That points more toward: * blocked I/O / database wait * an external system stall * or a process that stopped making progress rather than “it just needs more time.” My recommendation: * don’t just wait indefinitely * inspect the parent flow run’s crash message * inspect worker/container/pod logs * confirm whether the child run is still emitting logs If you want, send me: * the exact crash message from the parent flow run * how you’re running it (worker type: process, Docker, Kubernetes, ECS, etc.) * any timeout settings on the deployment / flow / task and I can help you determine whether this is a timeout, OOM, or a stuck-child-state situation. Relevant docs: * Flows * Tasks * Workers * Deployments