> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sluice.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Introduction

> Modern monitoring for Celery job queues — real-time visibility, search, retry, and alerting.

# See your Celery.

Sluice is a monitoring and management platform for Celery job queues. Connect your workers in under two minutes and get real-time visibility into every job, queue, and worker — with persistent history, search, and management actions that Flower never had.

## What you get

<CardGroup cols={2}>
  <Card title="Real-time job streaming" icon="bolt">
    Watch jobs flow through your queues as they happen. SSE-powered live updates with sub-second latency.
  </Card>

  <Card title="Search and filter" icon="magnifying-glass">
    Find any job by name, state, queue, or worker. Filter failed jobs, search by task name, sort by duration.
  </Card>

  <Card title="Retry and revoke" icon="rotate-right">
    Retry failed jobs or cancel running ones — individually or in bulk. Management actions Flower could never persist.
  </Card>

  <Card title="Persistent history" icon="clock-rotate-left">
    Every job is stored in Postgres with full state history and tracebacks. No more losing data when you refresh the page.
  </Card>
</CardGroup>

## Two ways to connect

Sluice offers two integration paths — pick the one that fits your workflow:

<CardGroup cols={2}>
  <Card title="Python SDK" icon="python" href="/quickstart/sdk">
    `pip install sluice-celery` — one import and one function call, auto-configures Celery events, richest data. Best for teams that own the Celery codebase.
  </Card>

  <Card title="Docker Agent" icon="docker" href="/quickstart/agent">
    `docker run ghcr.io/sluice-sh/agent` — zero code changes, reads Redis directly. Best for platform teams or when you can't modify the application.
  </Card>
</CardGroup>

## How it works

```mermaid theme={null}
graph LR
  A["Your Celery Workers"] -->|"Task events &
  worker heartbeats"| B["Sluice SDK or Agent"]
  B -->|"Normalize &
  batch events"| C["Sluice API"]
  C -->|"Persist to
  Postgres"| D[("Database")]
  D -->|"Real-time
  SSE stream"| E["Dashboard"]
```

The SDK hooks into Celery's event system via a Bootstep. The Go agent subscribes to Redis PUB/SUB channels and reads broker keys directly. Both normalize events into Sluice's unified data model and forward them to the Sluice API over HTTPS.

<Note>
  Sluice uses framework-agnostic terminology throughout — "jobs" instead of "tasks", unified state names instead of Celery-specific ones. This is intentional: the architecture supports multiple job queue frameworks (BullMQ, Sidekiq) in future versions.
</Note>

## Quick links

* [SDK Quickstart](/quickstart/sdk) — from zero to seeing data in under 2 minutes
* [Agent Quickstart](/quickstart/agent) — Docker-based, no code changes
* [SDK Reference](/sdk/reference) — every `sluice.init()` parameter documented
* [REST API Reference](/api/overview) — all endpoints with request/response examples
* [Troubleshooting](/troubleshooting/no-data) — common issues and fixes