What you’re seeing is consistent with a service wrapper / process management issue on Windows, not a Prefect worker registration issue. Why it happens - The worker does start successfully, which is why you see it in Prefect Cloud. - But when run as a Windows Service via Servy, the service manager appears to think the service process has exited or stopped responding after ~10 seconds. - Meanwhile, the underlying

python.exe

process can remain alive, so the worker keeps polling and still appears online in Cloud. The most likely trigger here is

--with-healthcheck

. In Prefect 3.x,

--with-healthcheck

starts a healthcheck server in a background thread. That pattern can behave poorly with Windows service wrappers because Windows service stop/start semantics don’t map cleanly to normal Python signal handling. Result: the service shows as stopped, but the Python child process keeps running. My recommendation 1. First try removing

--with-healthcheck

Run the worker service with:

D:\prefect-workflows\.venv\Scripts\python.exe -m prefect worker start --pool "colprefectprd" --name "worker_one"

2. If possible, use a different Windows service wrapper Users generally have better luck with tools like: - NSSM - WinSW 3. If you need health monitoring on Windows, prefer: - external monitoring of the worker process/service - or running the worker in Docker / WSL2 instead of a native Windows Service Why removing

--with-healthcheck

is the key test If the worker stays correctly attached to the service without that flag, then the issue is almost certainly the interaction between: - Prefect’s healthcheck server - Uvicorn/threaded startup - Windows service lifecycle handling in Servy Practical next step Please try this exact command in the service definition:

D:\prefect-workflows\.venv\Scripts\python.exe -m prefect worker start --pool "colprefectprd" --name "worker_one"

If that works, then the fix is likely: don’t use

--with-healthcheck

for a Windows Service managed by Servy. If you want, I can also help you with: - a known-good NSSM setup for a Prefect worker on Windows, or - a small wrapper script for Servy so it tracks the worker process correctly.

Good to know — thanks for sharing that. If

servy

only worked after enabling Console UI in the main setup panel, that’s a useful workaround/config detail and likely means the UI mode was affecting how the service initialized in your environment. I’ll keep that in mind for this conversation. If you want, I can also help you turn that into: - a short troubleshooting note - a reproducible setup checklist - or a GitHub discussion-worthy summary if this seems like an undocumented fix others might hit