Kick off a new Scan of a provider - Stuck in Queued status

[kfoxton]

Issue search

• I have searched the existing issues and this bug has not been reported yet

Which component is affected?

Prowler UI

Cloud Provider (if applicable)

Not applicable, AWS

Steps to Reproduce

Manually kicking off a scan of a configured Cloud Provider (AWS based),
Job is added to the queue, but no matter how long is waited, the scan never starts.
Kicking off other jobs will sometimes start, but the job in the queue never starts.

Expected behavior

The scan should start, scan, and finish.

Actual Result with Screenshots or Logs

Scan stays in Queued status (see screenshot above).

How did you install Prowler?

Docker (docker pull toniblyx/prowler)

Environment Resource

running on docker locally

OS used

Rocky Linux

Prowler version

5.22.0

Python version

docker

Pip version

docker

Context

No response

[danibarranqueroo]

Hi @kfoxton, thanks for the report! 🙏

A scan staying in Queued means the API accepted the scan and created the task, but the Celery worker never picked it up and executed it. A few things to help us pin down the cause:

1. The most common culprit: the worker being OOM-killed. The scan worker can be memory-hungry, and on local Docker setups (especially Docker Desktop or small VMs) it's frequently killed by the OOM killer mid-scan or on startup. That leaves scans sitting in Queued with nothing consuming them. Worth checking first:

• docker stats while a scan is queued — watch the worker's memory
• docker inspect <worker-container> --format '{{.State.OOMKilled}}'
• dmesg | grep -i "killed process" on the host

If you're memory-constrained, bumping the memory available to Docker usually resolves it.

2. Confirm the worker is running and connected to the broker. Please share:

• docker compose ps (is the worker container up and healthy?)
• The worker logs: docker compose logs worker — we're looking for connection errors to the broker (RabbitMQ/Valkey), tracebacks, or the container restarting in a loop.

3. Please upgrade. You're on 5.22.0, which is quite a few releases behind. Since then we've added per-provider scan queueing plus several fixes to scan dispatch and queue maintenance. Please update to the latest release and let us know if the issue persists — it may already be resolved.

Once we have the worker logs and memory info, we can dig in further. Thanks!

[kfoxton]

Hi @danibarranqueroo ,

After upgrading to the latest version, and restarting it twice. It looks like it is working now. The only item to note is that the items that were previously stuck as queued, as still there, in a queued state.

[danibarranqueroo]

Hello @kfoxton! Thanks for the update! For the problem with old scans stuck as queued we have this PR #12008. Once it's merged and released I'll let you know so you can try again 💯