Celery · AsyncAPI Specification

Celery Worker Event Stream

Version 5.6.3

Celery workers publish a monitoring event stream over the configured broker. This document is a faithful transcription of the published Event Reference in the Celery Monitoring and Management Guide — every channel, message and field below is named in that page and nothing has been added. IMPORTANT PROVENANCE: this AsyncAPI document was AUTHORED BY API EVANGELIST from Celery's documentation. Celery does not publish an AsyncAPI specification. It is a derivation, not a provider artifact — see x-generated-from below. The stream is off by default: it requires the worker to be started with -E/--task-events, or events to be enabled at runtime with `celery -A proj control enable_events`. task-sent additionally requires the task_send_sent_event setting. Events are published to the `celeryev` topic exchange on AMQP brokers; the event routing key is the event type name.

View Spec View on GitHub AsynchronousDistributed SystemsMessage QueueOpen-SourcePythonTask QueueAsyncAPIEventsAMQP

Channels

taskEvents
Lifecycle events for individual task executions.
workerEvents
Presence and heartbeat events for worker nodes.

Messages

taskSent
task-sent
Sent when a task message is published and the task_send_sent_event setting is enabled.
taskReceived
task-received
Sent when the worker receives a task.
taskStarted
task-started
Sent just before the worker executes the task.
taskSucceeded
task-succeeded
Sent if the task executed successfully.
taskFailed
task-failed
Sent if the execution of the task failed.
taskRejected
task-rejected
The task was rejected by the worker, possibly to be re-queued or moved to a dead letter queue.
taskRevoked
task-revoked
Sent if the task has been revoked. The documentation notes this is likely to be sent by more than one worker.
taskRetried
task-retried
Sent if the task failed, but will be retried in the future.
workerOnline
worker-online
The worker has connected to the broker and is online.
workerHeartbeat
worker-heartbeat
Sent every minute. If the worker hasn't sent a heartbeat in 2 minutes it is considered to be offline.
workerOffline
worker-offline
The worker has disconnected from the broker.

Servers

amqp
broker
The broker the Celery application is configured against. Events are carried on the same transport as tasks; on AMQP they are published to the `celeryev` topic exchange. Redis and other Kombu transports carry the same event payloads over their own primitives. The host is a variable because the consumer runs their own broker — Celery hosts nothing.

AsyncAPI Specification

celery-events-asyncapi.yml Raw ↑
asyncapi: 3.0.0
info:
  title: Celery Worker Event Stream
  version: '5.6.3'
  description: >-
    Celery workers publish a monitoring event stream over the configured broker. This document is a
    faithful transcription of the published Event Reference in the Celery Monitoring and Management
    Guide — every channel, message and field below is named in that page and nothing has been added.


    IMPORTANT PROVENANCE: this AsyncAPI document was AUTHORED BY API EVANGELIST from Celery's
    documentation. Celery does not publish an AsyncAPI specification. It is a derivation, not a
    provider artifact — see x-generated-from below.


    The stream is off by default: it requires the worker to be started with -E/--task-events, or
    events to be enabled at runtime with `celery -A proj control enable_events`. task-sent
    additionally requires the task_send_sent_event setting. Events are published to the `celeryev`
    topic exchange on AMQP brokers; the event routing key is the event type name.
  license:
    name: BSD-3-Clause
    url: https://github.com/celery/celery/blob/main/LICENSE
  externalDocs:
    description: Celery Monitoring and Management Guide — Event Reference
    url: https://docs.celeryq.dev/en/stable/userguide/monitoring.html#event-reference
x-generated-from: documentation
x-authored-by: API Evangelist (not the provider)
x-source-url: https://docs.celeryq.dev/en/stable/userguide/monitoring.html#event-reference
x-method: derived
x-generated: '2026-09-05'
defaultContentType: application/json
servers:
  broker:
    host: '{broker_host}'
    protocol: amqp
    description: >-
      The broker the Celery application is configured against. Events are carried on the same
      transport as tasks; on AMQP they are published to the `celeryev` topic exchange. Redis and
      other Kombu transports carry the same event payloads over their own primitives. The host is a
      variable because the consumer runs their own broker — Celery hosts nothing.
    variables:
      broker_host:
        description: Hostname of the broker the consumer operates.
        default: localhost
channels:
  taskEvents:
    address: celeryev
    title: Task events
    description: Lifecycle events for individual task executions.
    messages:
      taskSent:
        $ref: '#/components/messages/taskSent'
      taskReceived:
        $ref: '#/components/messages/taskReceived'
      taskStarted:
        $ref: '#/components/messages/taskStarted'
      taskSucceeded:
        $ref: '#/components/messages/taskSucceeded'
      taskFailed:
        $ref: '#/components/messages/taskFailed'
      taskRejected:
        $ref: '#/components/messages/taskRejected'
      taskRevoked:
        $ref: '#/components/messages/taskRevoked'
      taskRetried:
        $ref: '#/components/messages/taskRetried'
  workerEvents:
    address: celeryev
    title: Worker events
    description: Presence and heartbeat events for worker nodes.
    messages:
      workerOnline:
        $ref: '#/components/messages/workerOnline'
      workerHeartbeat:
        $ref: '#/components/messages/workerHeartbeat'
      workerOffline:
        $ref: '#/components/messages/workerOffline'
operations:
  receiveTaskEvents:
    action: receive
    channel:
      $ref: '#/channels/taskEvents'
    summary: Consume task lifecycle events (celery events, Flower, or a custom EventReceiver).
  receiveWorkerEvents:
    action: receive
    channel:
      $ref: '#/channels/workerEvents'
    summary: Consume worker presence and heartbeat events.
components:
  messages:
    taskSent:
      name: task-sent
      title: task-sent
      summary: Sent when a task message is published and the task_send_sent_event setting is enabled.
      payload:
        type: object
        properties:
          uuid: { type: string, description: Task id. }
          name: { type: string, description: Registered task name. }
          args: { type: string, description: Positional arguments. }
          kwargs: { type: string, description: Keyword arguments. }
          retries: { type: integer }
          eta: { type: string, description: Scheduled execution time, if set. }
          expires: { type: string }
          queue: { type: string }
          exchange: { type: string }
          routing_key: { type: string }
          root_id: { type: string, description: Id of the root task in the workflow. }
          parent_id: { type: string, description: Id of the parent task. }
    taskReceived:
      name: task-received
      title: task-received
      summary: Sent when the worker receives a task.
      payload:
        type: object
        properties:
          uuid: { type: string }
          name: { type: string }
          args: { type: string }
          kwargs: { type: string }
          retries: { type: integer }
          eta: { type: string }
          hostname: { type: string, description: Nodename of the worker. }
          timestamp: { type: number, description: Event time-stamp. }
          root_id: { type: string }
          parent_id: { type: string }
    taskStarted:
      name: task-started
      title: task-started
      summary: Sent just before the worker executes the task.
      payload:
        type: object
        properties:
          uuid: { type: string }
          hostname: { type: string }
          timestamp: { type: number }
          pid: { type: integer, description: Process id of the executing child process. }
    taskSucceeded:
      name: task-succeeded
      title: task-succeeded
      summary: Sent if the task executed successfully.
      payload:
        type: object
        properties:
          uuid: { type: string }
          result: { type: string }
          runtime:
            type: number
            description: >-
              Time it took to execute the task using the pool — from the task being sent to the
              worker pool until the pool result handler callback is called.
          hostname: { type: string }
          timestamp: { type: number }
    taskFailed:
      name: task-failed
      title: task-failed
      summary: Sent if the execution of the task failed.
      payload:
        type: object
        properties:
          uuid: { type: string }
          exception: { type: string }
          traceback: { type: string }
          hostname: { type: string }
          timestamp: { type: number }
    taskRejected:
      name: task-rejected
      title: task-rejected
      summary: The task was rejected by the worker, possibly to be re-queued or moved to a dead letter queue.
      payload:
        type: object
        properties:
          uuid: { type: string }
          requeue: { type: boolean }
    taskRevoked:
      name: task-revoked
      title: task-revoked
      summary: >-
        Sent if the task has been revoked. The documentation notes this is likely to be sent by more
        than one worker.
      payload:
        type: object
        properties:
          uuid: { type: string }
          terminated: { type: boolean, description: True if the task process was terminated. }
          signum: { type: integer, description: The signal used, when terminated is true. }
          expired: { type: boolean, description: True if the task expired. }
    taskRetried:
      name: task-retried
      title: task-retried
      summary: Sent if the task failed, but will be retried in the future.
      payload:
        type: object
        properties:
          uuid: { type: string }
          exception: { type: string }
          traceback: { type: string }
          hostname: { type: string }
          timestamp: { type: number }
    workerOnline:
      name: worker-online
      title: worker-online
      summary: The worker has connected to the broker and is online.
      payload:
        type: object
        properties:
          hostname: { type: string, description: Nodename of the worker. }
          timestamp: { type: number, description: Event time-stamp. }
          freq: { type: number, description: Heartbeat frequency in seconds (float). }
          sw_ident: { type: string, description: 'Name of worker software (e.g., py-celery).' }
          sw_ver: { type: string, description: 'Software version (e.g., 2.2.0).' }
          sw_sys: { type: string, description: 'Operating System (e.g., Linux/Darwin).' }
    workerHeartbeat:
      name: worker-heartbeat
      title: worker-heartbeat
      summary: >-
        Sent every minute. If the worker hasn't sent a heartbeat in 2 minutes it is considered to be
        offline.
      payload:
        type: object
        properties:
          hostname: { type: string }
          timestamp: { type: number }
          freq: { type: number }
          sw_ident: { type: string }
          sw_ver: { type: string }
          sw_sys: { type: string }
          active: { type: integer, description: Number of currently executing tasks. }
          processed: { type: integer, description: Total number of tasks processed by this worker. }
    workerOffline:
      name: worker-offline
      title: worker-offline
      summary: The worker has disconnected from the broker.
      payload:
        type: object
        properties:
          hostname: { type: string }
          timestamp: { type: number }
          freq: { type: number }
          sw_ident: { type: string }
          sw_ver: { type: string }
          sw_sys: { type: string }

Work with this as data

Every AsyncAPI spec here is available over the APIs.io API and to AI agents over MCP.

MCP server

One button, every client — Claude, Cursor, VS Code and the rest.

https://apis.io/mcp

Tools for asyncapi

4 MCP tools reach this
  • find_asyncapisBrowse and filter every AsyncAPI spec in the catalog.
  • apis_io_searchSTART HERE — APIs, providers and tags for one query, each with its total.
  • resolveTurn a domain, URL or GitHub org into the provider it belongs to.
  • find_cohortsEvery scored population of providers in the catalog.
All 92 tools →

Call it yourself

curl for this page
This AsyncAPI spec
curl "https://apis.io/api/v1/asyncapis/celery-events-asyncapi"
All asyncapi
curl "https://apis.io/api/v1/asyncapis?limit=25"

Discovery needs no key. Ratings and market analysis are Pro.

Get an API key

Free tier, no form to fill in. Signing in shares your email address with us — we store it to create your key and to recognise you if you sign in with another provider. See our Privacy Policy and Terms.

A second provider on the same verified email joins the account you already have.