<@ULVA73B9P> i could see prefect workpool is active，but its worker queue see no polling worker not...

Hui Wu

06/26/2026, 6:50 AM

@Marvin i could see prefect workpool is active，but its worker queue see no polling worker not its status is not ready. why could this happen

Marvin

06/26/2026, 6:50 AM

✅ thought for 134.8 seconds

Marvin

06/26/2026, 6:52 AM

Yes — this can happen in Prefect. A work pool being active/ready does not always mean a worker is currently polling a queue. Most likely, one of these is happening: 1. The worker process is not actually running - The work pool exists and is enabled - But no

prefect worker start --pool <pool-name>

process is alive - Result: queue shows no polling workers and not ready 2. The worker is running, but polling the wrong pool or wrong queue - The worker may be attached to another pool - Or it may be restricted to specific queues with

--work-queue

- If your deployment is in queue

, but worker only polls queue

, then that queue looks not ready 3. The worker lost connection / stopped polling - Sometimes the worker started before, so the pool still looks okay for a moment - But if it stops polling, the queue status becomes not ready 4. The worker type does not match the pool type - Example: Docker worker for a process pool, or Kubernetes worker for a docker pool - Then the pool may exist, but no usable worker is servicing it 5. The worker cannot reach Prefect API / Prefect Cloud - Network/auth issues can prevent polling - Then UI shows no polling workers What to check 1. Verify the worker is running Run on the machine where the worker should be running:

Copy code

bash
prefect worker start --pool <your-pool-name>

If it is already running, check its logs for polling messages or errors. 2. Inspect the work pool

Copy code

bash
prefect work-pool inspect <your-pool-name>

This confirms the pool exists and shows its configuration. 3. Confirm the worker is using the correct queue If you started worker with a queue restriction, make sure it matches the deployment queue:

Copy code

bash
prefect worker start --pool <your-pool-name> --work-queue <queue-name>

If unsure, start without

--work-queue

so it can poll all queues in that pool. 4. Check worker logs Look for errors like: - authentication/API errors - connection refused / timeout - wrong worker type - missing infrastructure dependencies Important distinction - Work pool active = pool is enabled/configured - Queue ready / polling worker visible = an actual worker is actively polling that queue So if queue says no polling worker / not ready, Prefect is basically telling you: “I do not currently see a worker polling this queue.” Verified CLI commands -

prefect worker start --help

prefect work-pool inspect --help

If you want, send me: - your worker start command - your pool type - whether you’re using a specific work queue - a screenshot or the output of

prefect work-pool inspect <pool>

and I can help pinpoint the exact cause.

Hui Wu

06/26/2026, 7:01 AM

@Marvin uv run prefect work-pool inspect ude-local-pool Prefect collects anonymous usage data to improve the product. To opt out: set PREFECT_SERVER_ANALYTICS_ENABLED=false on the server, or DO_NOT_TRACK=1 in the client. Learn more: https://docs.prefect.io/concepts/telemetry WorkPool( id='845f720b-6cdd-480a-bff9-6e8bc39be644', created=DateTime(2026, 6, 26, 4, 15, 1, 34559, tzinfo=Timezone('UTC')), updated=DateTime(2026, 6, 26, 4, 15, 1, 244456, tzinfo=Timezone('UTC')), name='ude-local-pool', type='process', base_job_template={ 'variables': { 'type': 'object', 'properties': { 'env': { 'type': 'object', 'title': 'Environment Variables', 'description': 'Environment variables to set when starting a flow run.', 'additionalProperties': {'anyOf': [{'type': 'string'}, {'type': 'null'}]} }, 'name': { 'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Name', 'default': None, 'description': 'Name given to infrastructure created by a worker.' }, 'labels': { 'type': 'object', 'title': 'Labels', 'description': 'Labels applied to infrastructure created by a worker.', 'additionalProperties': {'type': 'string'} }, 'command': { 'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Command', 'default': None, 'description': 'The command to use when starting a flow run. In most cases, this should be left blank and the command will be automatically generated by the worker.' }, 'working_dir': { 'anyOf': [{'type': 'string', 'format': 'path'}, {'type': 'null'}], 'title': 'Working Directory', 'default': None, 'description': 'If provided, workers will open flow run processes within the specified path as the working directory. Otherwise, a temporary directory will be created.' }, 'stream_output': { 'type': 'boolean', 'title': 'Stream Output', 'default': True, 'description': 'If enabled, workers will stream output from flow run processes to local standard output.' } } }, 'job_configuration': { 'env': '{{ env }}', 'name': '{{ name }}', 'labels': '{{ labels }}', 'command': '{{ command }}', 'working_dir': '{{ working_dir }}', 'stream_output': '{{ stream_output }}' } }, status=WorkPoolStatus.READY, storage_configuration=WorkPoolStorageConfiguration(), default_queue_id='6ac55af7-f21b-423c-8fae-ab05af451bac' )

Marvin

06/26/2026, 7:01 AM

✅ thought for 23.5 seconds

Marvin

06/26/2026, 7:01 AM

Thanks — this output is helpful. Your pool is: - name:

ude-local-pool

- type:

process

- status:

READY

That means Prefect knows about the pool, but it does not yet prove that a worker is actively polling the queue right now. Since this is a process pool, the most common causes are: 1. No local process worker is running anymore For a

process

pool, you need a worker process continuously running somewhere:

Copy code

bash
prefect worker start --pool ude-local-pool --type process

If that command is not currently running, the queue will show no polling worker / not ready. 2. The worker is running in another shell/session and stopped silently This is very common with local workers. If the terminal was closed, the worker stopped. 3. The worker is polling a different queue Your pool has a

default_queue_id

, but if your worker was started with

--work-queue some-other-queue

, it may not be polling the queue your deployment uses. 4. Temporary UI/status delay Sometimes pool status remains

READY

briefly even when queue readiness is stale. Queue readiness is tied to active polling. What I’d check next Step 1: start a fresh worker explicitly On the same machine where your flow code is available, run:

Copy code

bash
uv run prefect worker start --pool ude-local-pool --type process

Then watch the logs. You should see it begin polling. Step 2: if it starts successfully, refresh the UI The queue status should change to ready once polling is detected. Step 3: if it still says no polling worker, check whether your deployment uses a non-default queue If you deployed to a named queue, start the worker with that queue too:

Copy code

bash
uv run prefect worker start --pool ude-local-pool --type process --work-queue <queue-name>

Step 4: check for worker log errors Common errors: - cannot connect to Prefect API / Cloud - wrong

PREFECT_API_URL

- missing project code / wrong working directory - environment mismatch One more important point about
process
pools A

process

worker must run on a machine that already has: - your Python environment - your flow code available - Prefect installed - correct API configuration Unlike Docker/Kubernetes workers,

process

workers do not create isolated infrastructure automatically. Likely diagnosis Based on what you shared, the most likely explanation is simply: The pool exists and is marked READY, but there is no currently running process worker actively polling
ude-local-pool
. If you want, send me the output of starting:

Copy code

bash
uv run prefect worker start --pool ude-local-pool --type process

and I can help interpret it.

Hui Wu

06/26/2026, 7:05 AM

@Marvin #ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 0 14:49 ? 000000 sh /UAE-META/start.sh root 82 1 0 14:49 ? 000000 /usr/sbin/crond root 130 1 0 14:49 ? 000000 sh /home/admin/app/run.sh root 131 130 0 14:49 ? 000000 uv run prefect worker start --pool ude-local-pool root 132 130 0 14:49 ? 000000 tail -f /home/admin/app/logs/uae-stop.log root 147 131 0 14:49 ? 000003 /home/admin/app/knowsphere/.venv/bin/python /home/admin/app/knowsphere/.venv/bin/prefect worker star root 186 0 0 14:54 pts/0 000000 bash root 373 186 0 15:04 pts/0 000000 ps -ef uv run prefect worker start --pool ude-local-pool > /home/admin/app/logs/worker_std_out 2>&1 &

Marvin

06/26/2026, 7:05 AM

✅ thought for 10.0 seconds

Marvin

06/26/2026, 7:05 AM

Thanks — this confirms a lot. You do have a worker process running:

Copy code

bash
uv run prefect worker start --pool ude-local-pool

and the actual Prefect worker process appears here too:

Copy code

bash
/home/admin/app/knowsphere/.venv/bin/python ... prefect worker start ...

So if the UI still says no polling worker / queue not ready, the likely causes narrow to these: 1. The worker process is alive, but not successfully polling the API The process existing in

ps -ef

only means it started. It does not guarantee it connected to Prefect and is polling. This is the most likely issue now. Please inspect the worker log file:

Copy code

bash
tail -n 100 /home/admin/app/logs/worker_std_out

Look for messages like: - authentication errors - connection refused - wrong workspace/API URL - repeated retries - import/environment issues 2. The worker may be connected to a different Prefect API/workspace If

PREFECT_API_URL

is wrong, the worker can run but poll the wrong server/workspace. Check:

Copy code

bash
uv run prefect config view

Pay attention to: -

PREFECT_API_URL

If using Cloud, confirm it points to the correct workspace. If using Server, confirm it points to the correct server. 3. The worker may be failing right after startup and getting restarted Sometimes

ps

catches a running wrapper process, but the real worker may be erroring/restarting. So also check whether the log is actively updating:

Copy code

bash
tail -f /home/admin/app/logs/worker_std_out

You want to see healthy messages indicating the worker is polling. 4. Queue mismatch is still possible You started the worker without

--work-queue

, which usually means it can poll all queues in that pool, so this is less likely. But if your deployment targets a specific queue with some unusual config, we should confirm later if needed. What healthy behavior should look like A healthy process worker should log things indicating: - worker started - connected to Prefect API - polling work pool

ude-local-pool

If you don’t see that, then the worker is not truly active from Prefect’s perspective. Most useful next commands Run these and share the outputs:

Copy code

bash
tail -n 100 /home/admin/app/logs/worker_std_out

Copy code

bash
uv run prefect config view

If you want, also try running the worker in the foreground temporarily instead of backgrounding it:

Copy code

bash
uv run prefect worker start --pool ude-local-pool --type process

That often makes the problem obvious immediately. At this point, I do not think the issue is “no worker process exists.” I think it is more likely: worker process exists, but it is not successfully registering/polling the Prefect API.

4 Views

Open in Slack

Previous Next

Prefect Community

Bring your towel and join one of the fastest growing data communities. Welcome to our second-generation open source orchestration platform, a completely rethought approach to dataflow automation.