KubeMQ
IntegrationsCeleryHow-to guides

Troubleshooting & FAQ

Diagnose and fix common kubemq-celery issues — connection failures, tasks not executing, duplicate runs, missing results, and monitoring gaps.

This guide collects the issues you are most likely to hit running Celery on KubeMQ, grouped by symptom: connection failures, tasks that do not execute or run twice, missing results, the "unknown transport" import error, and monitoring gaps. Each entry gives the cause and a concrete fix. For the underlying transport model see Concepts; for every option referenced here see Transport Options.

Connection issues

Task issues

Configuration issues

Performance issues

Monitoring issues

KubeMQ vs Redis — issue comparison

IssueRedis behaviorKubeMQ behavior
Message loss on restartLost unless AOF/RDB persistence is configuredPersistent storage by default
Duplicate task executionVisibility-timeout race causes duplicatesNative ack/nack (no duplicates with acks_early)
Worker connection dropsSilent failure, manual recoverygRPC keepalive, auto-reconnect via Celery retry
DLQ for failed tasksManual implementationNative max_receive_count + dead_letter_queue
Delayed-task OOMTasks held in worker memory (client polling)Server-side delay_in_seconds (zero worker memory)
Connection exhaustion6–8 TCP connections per worker2–3 gRPC connections (HTTP/2 multiplexed)
Queue-depth monitoringCustom scripts or Redis CLIREST /queue/info on 9090 plus the Management API dashboard on 8080
Broker failoverSentinel or Cluster mode requiredKubernetes-native StatefulSet auto-clustering

When Redis may still be appropriate

  • Sub-millisecond latency for small payloads (Redis is in-memory).
  • Existing Redis infrastructure already deployed and managed.
  • Result retention beyond 24 hours — KubeMQ caps expiration at 86400 seconds.
  • Native O(1) chord unlock — KubeMQ uses a polling fallback (see Canvas Workflows).

Was this page helpful?

On this page