checkId: check.servicegraph.mq plugin: stellaops.doctor.servicegraph severity: warn tags: [servicegraph, messaging, rabbitmq, connectivity]

Message Queue Connectivity

This Doctor check helps operators confirm that Stella Ops can reach its RabbitMQ broker, so asynchronous release tasks, notifications, and deferred work do not silently back up.

What It Checks

Reads RabbitMQ:Host or Messaging:RabbitMQ:Host plus an optional port, defaulting to 5672, and attempts a TCP connection.

Condition	Result
RabbitMQ not configured	`skip`
TCP connection succeeds	`pass`
Timeout, DNS failure, or refused connection	`fail`

Why It Matters

Release tasks, notifications, and deferred work often depend on a functioning message broker. A dead queue path turns healthy APIs into backlogged systems.

Common Causes

RabbitMQ__Host is unset or points to the wrong broker
The broker container is down
AMQP traffic is blocked between Doctor and RabbitMQ

How to Fix

Docker Compose

services:
  doctor-web:
    environment:
      RabbitMQ__Host: rabbitmq
      RabbitMQ__Port: "5672"

docker compose -f devops/compose/docker-compose.stella-ops.yml ps rabbitmq
docker compose -f devops/compose/docker-compose.stella-ops.yml logs --tail 100 rabbitmq
docker compose -f devops/compose/docker-compose.stella-ops.yml exec doctor-web sh -lc "nc -zv rabbitmq 5672"

Bare Metal / systemd

nc -zv <rabbit-host> 5672

Kubernetes / Helm

kubectl exec deploy/doctor-web -n <namespace> -- sh -lc "nc -zv <rabbit-service> 5672"

Verification

stella doctor run --check check.servicegraph.mq

check.servicegraph.valkey — cache and queue connectivity usually fail together when service networking is broken
check.servicegraph.timeouts — aggressive timeouts can make a slow broker look unavailable