What this prompt does
This prompt sets up a full Celery task system for a Django project. You define the [project_type] and the kinds of work to run asynchronously via [task_examples], and the AI configures a Celery app in [project_name]/celery.py with your [broker_type] broker, [result_backend], serializer, time limits (soft=[soft_limit]s and hard=[hard_limit]s), and concurrency tuned for [worker_type] workers.
The design centers on resilience. It produces a base task class that auto-retries transient errors like ConnectionError and Timeout with exponential backoff up to [max_retries], using task_acks_late=True and reject_on_worker_lost=True for critical work so a crash doesn't silently drop a task. Rate-limited tasks use [rate_limit] for [rate_limited_tasks] to stay under third-party API caps. The [complex_workflow] is expressed with chain() for sequential steps, group() for parallel work, and a chord() callback, while [periodic_tasks] run through Celery Beat with django-celery-beat and timezone handling. Priority queues from [queue_definitions] route work by urgency and resource need, and [monitoring_tool] watches success and failure rates, queue depth, and worker utilization, alerting when backlog exceeds [backlog_threshold].
When to use it
- You have slow or flaky operations (emails, payments, third-party calls) blocking request latency
- You need automatic retries with backoff so a downstream outage doesn't cascade
- You're hitting rate limits on external APIs and need throttled task execution
- You want a multi-step workflow expressed as sequential chains plus parallel groups with a callback
- You need scheduled jobs like nightly reports or hourly syncs via Celery Beat
- You want priority queues so payments never wait behind bulk analytics
- You need monitoring that alerts before a backlog quietly turns into a backlog incident
Example output
The AI returns a celery.py configuration block, a base task class with retry decorators and backoff, example @shared_task definitions for rate-limited and queued work, a chain/group/chord workflow for [complex_workflow], a Beat schedule dict for [periodic_tasks], queue routing config for [queue_definitions], and a monitoring section describing what [monitoring_tool] should track and where the [backlog_threshold] alert fires. Expect organized code snippets per numbered concern, not a single file.
Pro tips
- Match
[soft_limit]and[hard_limit]to your real task durations — too tight and legitimate work gets killed, too loose and hung tasks tie up workers - Be specific in
[rate_limited_tasks]so only external-API tasks get throttled, not internal fast ones - Define
[queue_definitions]by resource profile (critical, default, bulk, low) so routing actually isolates blast radius - Set
[backlog_threshold]based on observed throughput, not a guess, so alerts are meaningful - Keep
task_acks_late=Trueonly for idempotent critical tasks; for non-idempotent work it can cause duplicate execution on retry - Tune
[worker_type]concurrency to the workload: CPU-bound resizing wants fewer processes than IO-bound API calls - If the workflow section is vague, re-prompt with the exact ordering of
[complex_workflow]steps spelled out
