Documentation · KioMQ docs

KioMQ gives you three things: a queue to enqueue jobs, one or more workers to process them concurrently, and a pluggable store that owns the state. Everything else — scheduling, retries, events, metrics — is built on top of those primitives.

If you are new here, read Getting started and then Quick start . If you already have a queue running, jump straight to Configuration or the API reference on docs.rs.

Getting started Install KioMQ, satisfy the Tokio runtime requirements, and pick the feature flags you need. Quick start Enqueue jobs and process them with an async or a sync worker, end to end, in a single file. Core concepts How a job moves through the queue, who owns which piece of state, and what happens when a worker dies. Configuration Queue defaults, per-job overrides, and worker tuning — every option, with its default value. Scheduling Delays, priority scores, cron expressions, and repeat policies — everything about when a job runs. Errors & retries How failures are signalled, what happens to a panicking processor, and how backoff decides when to try again. Events Subscribe to job state transitions, match on typed payloads, and choose between streamed and broadcast … Progress Report typed progress from inside a processor — persisted to the store and emitted as an event. Metrics Queue counters, process snapshots, and per-worker task timings — collected automatically, with no extra setup. Backends In-memory for tests, Redis for production fleets — both behind one Store trait. Changelog Every released version of KioMQ, generated from the repository's CHANGELOG.md so it can never drift from the … Benchmarks Run the Criterion suite locally — the only numbers worth trusting are the ones from your own hardware. Testing Run the suite with cargo-nextest, and write tests against your own queues without touching Redis. Contributing Set up the repo hooks, know what CI will check, and where to ask questions.