Monitor Celery Task Queues with Flower

Flower is a real-time, web-based dashboard for monitoring and administering Celery workers and tasks. Install it with pip install flower and start it against your app with a single command, celery -A proj flower --port=5555, then open http://localhost:5555 in your browser.

From that dashboard you can watch workers come online, follow tasks as they move from received to started to succeeded or failed, inspect each task's arguments, runtime and traceback, and revoke or rate-limit tasks without opening a shell.

Key takeaways

• Flower is the standard real-time monitor for Celery 5.x; it reads the worker event stream and your broker to show live state.
• Run it the modern way: celery -A proj flower --port=5555. The broker is picked up from your Celery app, so the old flower -A / celery flower -A argument-ordering pitfalls are gone.
• The default port is 5555; the dashboard, an HTTP API, and a Prometheus /metrics endpoint all live there.
• Never expose port 5555 to the public internet. Add --basic-auth or OAuth, bind it to localhost, and put Flower behind Nginx with TLS.
• For long-term metrics and alerting, pair Flower (or a celery-exporter) with Prometheus and Grafana.

# Install Flower into the same virtualenv as your Celery app
pip install flower

# Start the dashboard on the default port (5555)
celery -A proj flower --port=5555

# Then open http://localhost:5555 in your browser

What is Flower?

Flower is an open-source web application for monitoring and managing Celery clusters. Celery itself only emits events; Flower turns those events into a live UI plus a REST API. It connects to the same message broker as your workers (Redis or RabbitMQ) and subscribes to the worker event stream, so what you see updates in real time as tasks run.

In practice you reach for Flower to answer day-to-day operational questions: Are my workers up? Is the queue backing up? Which task just failed, and with what arguments? It complements Celery's command-line tools (celery inspect, celery events) with a shareable dashboard the whole team can open.

Install and run Flower

Flower is a separate package, but it must run in the same virtual environment as your Celery project so it can import your app. You also need a running broker. Redis is the most common choice today; RabbitMQ is still fully supported and gives Flower richer broker-queue insight through its management API.

A minimal Celery app looks like this. Save it as proj/celery.py:

# proj/celery.py
from celery import Celery

# The first argument is the app name; the broker and result backend point at
# Redis running locally. Swap in your RabbitMQ URL
# (amqp://guest:guest@localhost:5672//) if you use RabbitMQ instead.
app = Celery(
    "proj",
    broker="redis://localhost:6379/0",
    backend="redis://localhost:6379/1",
)

# Optional: load settings from Django (CELERY_* keys) and auto-discover tasks.
# app.config_from_object("django.conf:settings", namespace="CELERY")
# app.autodiscover_tasks()


@app.task
def add(x, y):
    return x + y

Start Flower the modern way

With Celery 5.x, every sub-command is invoked through the celery CLI, with the app passed via -A before the sub-command. Flower is no exception. The broker is read from your app, so you rarely need to repeat it:

# Correct (Celery 5.x): app first, then the flower sub-command
celery -A proj flower --port=5555

# Bind to a specific address and set the broker explicitly if needed
celery -A proj flower --address=127.0.0.1 --port=5555 \
  --broker=redis://localhost:6379/0

# RabbitMQ users: point Flower at the management API for live queue depths
celery -A proj flower --port=5555 \
  --broker=amqp://guest:guest@localhost:5672// \
  --broker-api=http://guest:guest@localhost:15672/api/

# Deprecated orderings you may see in old tutorials - avoid these:
#   flower -A proj ...
#   celery flower -A proj ...

What you can monitor and control

Once Flower is running, the dashboard gives you:

• Workers - every online worker, its status, concurrency pool, active and processed counts, load average and registered tasks.
• Tasks - a searchable, filterable list of tasks with their state (PENDING, STARTED, SUCCESS, FAILURE, RETRY, REVOKED), arguments, return value, runtime and full traceback on failure.
• Real-time graphs - throughput and success/failure rates over time, plus per-task breakdowns.
• Broker view - queue names and message counts (queue depth needs the RabbitMQ management API, or is inferred for Redis).
• Remote control - revoke or terminate a running task, set per-worker rate limits, grow or shrink the worker pool, and shut workers down, all from the UI.

Every one of these is also available over HTTP, which makes Flower scriptable, not just clickable.

Flower vs other Celery monitoring options

Flower is the fastest way to a live view, but it is not the only tool. Here is how the common options compare:

Tool	What it shows	Real-time?	Best for
Flower (web UI)	Workers, tasks, args, runtime, graphs, broker queues; remote control	Yes	Day-to-day ops, debugging a failing task, a shared dashboard
celery inspect / celery control (CLI)	Active, scheduled and reserved tasks, stats; revoke and rate-limit	On demand	Quick checks and scripts over SSH, no extra service
celery events (curses)	Live task and worker event stream in the terminal	Yes	A lightweight terminal monitor when a web app is not an option
Prometheus + Grafana (Flower /metrics or celery-exporter)	Time-series metrics, dashboards, alerting	Near real-time	Long-term trends, SLOs and on-call alerts
Broker UIs (RabbitMQ Management, Redis tools)	Queue depth, connections, broker health	Yes	Broker-level problems (backlogs, connection storms)

A common production setup is Flower for live inspection plus Prometheus and Grafana for history and alerts.

Securing Flower in production

By default Flower listens on 0.0.0.0:5555 with no authentication, so anyone who can reach the port can read your task arguments and revoke tasks. Never expose port 5555 directly to the internet. Lock it down in layers.

1. Add authentication

The simplest option is HTTP basic auth. For teams, wire up OAuth (Google or GitHub) so access follows your existing accounts:

# Basic auth: one or more user:password pairs, comma-separated
celery -A proj flower --port=5555 \
  --basic-auth=admin:$FLOWER_PASSWORD

# Google OAuth: restrict the dashboard to your company domain
celery -A proj flower --port=5555 \
  --auth=".*@yourcompany\.com" \
  --auth_provider=flower.views.auth.GoogleAuth2LoginHandler \
  --oauth2_key=$GOOGLE_OAUTH2_KEY \
  --oauth2_secret=$GOOGLE_OAUTH2_SECRET \
  --oauth2_redirect_uri=https://flower.yourcompany.com/login

2. Put Flower behind Nginx with TLS

Bind Flower to localhost and let Nginx terminate TLS and forward only authenticated traffic. Start Flower with --address=127.0.0.1 so it is not reachable directly, then proxy to it. Flower uses WebSockets for live updates, so the proxy must allow the connection upgrade:

# /etc/nginx/sites-available/flower
server {
    listen 443 ssl;
    server_name flower.yourcompany.com;

    ssl_certificate     /etc/letsencrypt/live/flower.yourcompany.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/flower.yourcompany.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:5555;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # WebSocket upgrade for Flower's live updates
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

3. Run Flower as a managed service

Do not run Flower in a stray terminal. Supervise it like any other long-running process so it restarts on failure and on reboot. systemd is the modern default; many teams still use Supervisor, especially alongside their Celery workers. See our guides on running Celery under Supervisor and daemonizing any command with Supervisor for the worker side.

A systemd unit for Flower:

# /etc/systemd/system/flower.service
[Unit]
Description=Celery Flower monitor
After=network.target redis-server.service

[Service]
User=www-data
Group=www-data
WorkingDirectory=/srv/proj
Environment="FLOWER_PASSWORD=change-me"
ExecStart=/srv/proj/venv/bin/celery -A proj flower \
    --address=127.0.0.1 --port=5555 \
    --basic-auth=admin:${FLOWER_PASSWORD}
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

# Enable and start the systemd service
sudo systemctl daemon-reload
sudo systemctl enable --now flower

# Or run Flower in Docker (official image), reachable on localhost only
docker run -d --name flower -p 127.0.0.1:5555:5555 \
  -e CELERY_BROKER_URL=redis://redis:6379/0 \
  mher/flower:latest \
  celery flower --basic-auth=admin:change-me

HTTP API and Prometheus metrics

Everything in the UI is backed by a REST API, and Flower also exports Prometheus metrics. That makes it easy to script health checks or feed dashboards and alerts:

# List workers and their status as JSON
curl http://localhost:5555/api/workers

# Get details for a single task by id
curl http://localhost:5555/api/task/info/<task_id>

# Asynchronously call a task over HTTP
curl -X POST -d '{"args":[2,3]}' \
  http://localhost:5555/api/task/async-apply/proj.add

# Revoke (and terminate) a running task
curl -X POST "http://localhost:5555/api/task/revoke/<task_id>?terminate=true"

# Prometheus metrics endpoint (scrape this from Prometheus)
curl http://localhost:5555/metrics

Alternatives and complements to Flower

Flower covers live monitoring well, but a complete observability story usually combines a few tools:

• celery inspect and celery events ship with Celery and need no extra service - perfect for a quick look over SSH. The commands below cover the essentials.
• Prometheus + Grafana give you history, dashboards and alerting. Scrape Flower's /metrics, or run a dedicated celery-exporter for richer task metrics, then build Grafana panels and alert rules on top.
• Broker dashboards (the RabbitMQ Management plugin, Redis monitoring) are the right tool when the problem is at the broker, not the worker.

If most of your tasks are scheduled, also see our guide to creating periodic tasks in Celery, and the Django and Celery best practices we follow on client projects. When you would rather hand off running all of this, our server maintenance and DevOps team sets up and operates Celery, Flower and alerting in production.

# Snapshot of currently executing tasks across all workers
celery -A proj inspect active

# Tasks reserved by a worker but not yet started
celery -A proj inspect reserved

# Worker statistics (pool size, totals, resource usage)
celery -A proj inspect stats

# Live, curses-style event monitor in the terminal
celery -A proj events

Frequently Asked Questions

What is Celery Flower used for?

Flower is a real-time, web-based dashboard for monitoring and administering Celery. It shows live worker status, task history with arguments and tracebacks, throughput graphs and broker queues, and it lets you revoke, terminate or rate-limit tasks. It also exposes an HTTP API and a Prometheus metrics endpoint for automation and alerting.

How do I start Flower with Celery 5.x?

Install it with pip install flower, then run celery -A proj flower --port=5555 from the same virtual environment as your app, where proj is your Celery app module. Open http://localhost:5555 to view the dashboard. The app is passed with -A before the flower sub-command; the older flower -A and celery flower -A orderings are deprecated.

What port does Flower run on?

Flower listens on port 5555 by default and binds to all interfaces (0.0.0.0). Change it with --port, and restrict the bind address with --address=127.0.0.1 so only the local machine or a reverse proxy can reach it.

How do I secure Flower in production?

Never expose port 5555 to the public internet. Add --basic-auth=user:password or OAuth, bind Flower to 127.0.0.1, and put it behind Nginx with TLS and authentication. Run it under systemd, Supervisor or Docker so it restarts automatically. Anyone who can reach an unsecured Flower can read task arguments and revoke tasks.

Does Flower work with Redis and RabbitMQ?

Yes. Flower works with any broker Celery supports, including Redis and RabbitMQ. It reads the broker URL from your Celery app, so the same celery -A proj flower command works for both. For live queue-depth numbers with RabbitMQ, also pass --broker-api pointing at the RabbitMQ management API.

Can Flower export metrics to Prometheus and Grafana?

Yes. Flower exposes a Prometheus-compatible /metrics endpoint (for example http://localhost:5555/metrics) that you can scrape into Prometheus and visualize in Grafana. For richer per-task metrics, many teams add a dedicated celery-exporter alongside Flower.