specification: API Commons Rate Limits
specificationVersion: '0.1'
schema: https://raw.githubusercontent.com/api-evangelist/interface-research/main/schema/api-commons.yml#/$defs/RateLimits
provider: Celery
providerId: celery
generated: '2026-09-05'
method: searched
source: >-
  https://docs.celeryq.dev/en/stable/userguide/tasks.html,
  https://docs.celeryq.dev/en/stable/userguide/workers.html,
  https://docs.celeryq.dev/en/stable/userguide/configuration.html
created: '2026-05-04'
modified: '2026-09-05'
tags:
  - Asynchronous
  - Distributed Systems
  - Message Queue
  - Open Source
  - Python
  - Task Queue
  - Rate Limiting
  - Throttling
limit_count: 0
limits: []
headers: {}
responseCodes: {}
description: >-
  Celery imposes no rate limits on consumers, because there is no hosted service and no HTTP
  surface: there are no X-RateLimit-* / RateLimit-* response headers, no Retry-After, and no 429,
  since there are no HTTP responses at all. limit_count is 0 as a measured fact.
note: >-
  This file REPLACES a fabricated scaffold written by the 2026-05-04 bulk sweep, which invented
  10/min free, 100/min professional and 1000/min enterprise API-key limits together with a full set
  of X-RateLimit-* response headers. None of those exist.
mechanism:
  provided: true
  kind: >-
    Celery is a rate LIMITER, not a rate-limited service. It publishes a throttling mechanism the
    operator configures for their own tasks. Recorded here because it is the real, documented
    rate-limit surface a consumer needs, even though it is not a limit imposed on them.
  controls:
    - name: Task.rate_limit
      scope: per task, per worker instance
      syntax: >-
        An integer or float is interpreted as tasks per second; a string may append "/s", "/m" or
        "/h" — e.g. "100/m" is a hundred tasks a minute, which enforces a minimum 600 ms delay
        between two task starts on the same worker instance.
      default: task_default_rate_limit — unset by default, meaning task rate limiting is disabled
      caveat: >-
        Documented explicitly as a PER WORKER INSTANCE limit, not a global one. The docs state that
        to enforce a global rate (for example against a downstream API with a maximum requests per
        second) you must restrict the task to a dedicated queue.
      docs: https://docs.celeryq.dev/en/stable/userguide/tasks.html
    - name: control rate_limit
      scope: runtime change, per task name
      syntax: celery -A proj control rate_limit <task_name> <rate>
      docs: https://docs.celeryq.dev/en/stable/userguide/workers.html
    - name: worker_prefetch_multiplier
      scope: per worker
      description: How many messages a worker prefetches per concurrency slot; the primary flow-control knob.
      docs: https://docs.celeryq.dev/en/stable/userguide/configuration.html
    - name: Task.time_limit / Task.soft_time_limit
      scope: per task
      description: >-
        Hard and soft execution ceilings. The soft limit raises SoftTimeLimitExceeded so the task can
        clean up; the hard limit terminates the task process.
      docs: https://docs.celeryq.dev/en/stable/userguide/workers.html
    - name: autoscale
      scope: per worker
      description: Dynamically grow and shrink the pool between a min and max concurrency.
      docs: https://docs.celeryq.dev/en/stable/userguide/workers.html
  backoff:
    mechanism: retry_backoff
    description: >-
      Exponential backoff with random jitter on automatic retries, capped at a maximum delay of 10
      minutes by default; tunable with retry_backoff_max and retry_jitter.
    docs: https://docs.celeryq.dev/en/stable/userguide/tasks.html
maintainers:
  - FN: Kin Lane
    email: kin@apievangelist.com