> ## Documentation Index > Fetch the complete documentation index at: https://getkanari.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Introduction > Privacy-first monitoring agent for Celery + Redis queues ## What is Kanari? Kanari is a monitoring agent built specifically for Celery + Redis. It detects the problems that generic monitoring tools miss, ghost workers, queue latency, stuck tasks, and silent task loss, and tells you exactly what's wrong and how to fix it. ```bash theme={null} pip install kanari kanari init # generate kanari.yaml (auto-detects REDIS_URL) kanari audit # auto-loads kanari.yaml from current directory ``` No account needed. No external service. Point it at your Redis and get a full health report in under a minute. *** ## The problem with generic monitoring Tools like Datadog and Grafana can tell you CPU and memory. They don't understand Celery's queue model, worker pool semantics, or task acknowledgment lifecycle. The most common Celery production failure looks like this: **workers show as running, the queue keeps growing, nobody knows why.** This happens because: * Workers reconnected to Redis after a blip but stopped consuming * All worker slots are full with one slow task type * `task_acks_late=False` means tasks silently vanished on the last deploy * Queue latency is spiking but there's no timestamp in the messages to measure it Datadog sees healthy CPU. Kanari sees the actual problem. *** ## How it works Kanari connects directly to your Redis and Celery instances, the same way your workers do, and collects: * **Queue depth** per queue (via Redis `LLEN`) * **Queue latency** — age of the oldest waiting task (requires [KanariStampPlugin](/docs/docs/guides/latency-tracking)) * **Worker health** — active tasks, concurrency slots, alive/offline status * **Stuck tasks** — tasks running beyond your configured threshold * **Configuration risks** — `task_acks_late`, prefetch settings, Redis eviction policy It then runs a [findings engine](/docs/docs/reference/findings) that produces structured observations: what's wrong, why it's probably happening, how to confirm it, and what to do about it. *** ## Commands Generate a starter kanari.yaml. Auto-detects connection URLs from the environment and probes Redis. Diagnose setup issues. Checks connectivity, libraries, config, and API key before you run anything else. One-shot health check. Prints a report and exits with a status code. Great for CI/CD or debugging an incident. Live dashboard that refreshes every N seconds. Use during an incident to see changes in real time. Continuous monitoring daemon. Sends metrics to Kanari for persistent monitoring and Slack/email alerts. Authenticate with Kanari via magic link. Saves your API key to \~/.kanari/config automatically. *** ## Two ways to use Kanari **Without an account — free forever** `kanari audit` and `kanari watch` work immediately with no account. Just point them at your Redis and Celery and run. **With a Kanari account — alerts + history** `kanari login` connects the agent to your Kanari account. After that, `kanari agent` runs in the background and sends you Slack or email alerts the moment something breaks. ```bash theme={null} # Free: generate config and run a health check kanari init kanari audit # auto-loads kanari.yaml # Paid: continuous monitoring with alerts kanari login kanari alerts configure --slack-webhook https://... kanari agent # auto-loads kanari.yaml ``` *** ## Privacy The agent never accesses task arguments, results, or payloads. Worker names and task IDs are hashed. Task signatures are sanitized to remove emails, UUIDs, and numeric IDs before any data leaves your infrastructure. See [Privacy & Data](/docs/docs/reference/privacy) for the full breakdown. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.