🤖 Automating RabbitMQ With the Management API and AI

I once wrote a perfectly reasonable health-check script that polled /api/queues every fifteen seconds and watched it show up as a noticeable CPU bump on the very broker it was supposed to be monitoring. The management API is the most convenient automation surface RabbitMQ gives you, and it’s also a loaded gun, because the friendly-looking endpoints have wildly different costs. /api/aliveness-test is nearly free; /api/queues recomputes per-queue statistics and gets expensive fast on a cluster with thousands of queues. The API will let you hurt yourself, and it won’t warn you first.

This is a place where AI is genuinely helpful and also genuinely overconfident. It can produce a working script against the API in seconds — but its first draft usually enumerates everything, polls aggressively, and runs as admin. The model knows the endpoints; it doesn’t, by default, respect their cost. So you draft with it and then make it defend the load profile.

Ask for the cheapest endpoint that answers the question

The right framing is cost-first. Tell the AI what you need to know and ask for the lightest endpoint that answers it.

I want a script that checks whether each vhost on my RabbitMQ cluster is healthy and flags any queue over a depth threshold. The cluster has a few thousand queues. Which management API endpoints should I use to minimize load on the broker, and how should I filter and paginate so I’m not pulling full per-queue stats every poll?

A good answer reaches for /api/aliveness-test/<vhost> or the lighter /api/health/checks/... endpoints for liveness, and uses column filtering on /api/queues rather than pulling the full object. If the model reflexively suggests fetching all queues with all fields on a tight interval, that’s the moment to push back.

Filter columns and slow the loop down

The single highest-leverage move is asking only for the columns you need. Pulling full queue objects on a large cluster is the expensive path.

# Cheap liveness check per vhost
curl -s -u monitor:secret \
  http://localhost:15672/api/aliveness-test/%2F

# Reduced-column queue audit instead of full objects
curl -s -u monitor:secret \
  'http://localhost:15672/api/queues?columns=name,vhost,messages,state'

The ?columns= filter is the difference between a query that returns a slim list and one that makes the node compute and serialize every statistic for every queue. Combine that with a conservative interval — minutes, not seconds, for full audits — and your automation stops competing with the workload for the broker’s attention.

Use a least-privilege user and make writes idempotent

Stats collection does not need admin. Create a dedicated read-only user with the monitoring tag, and keep its credentials out of the script.

rabbitmqctl add_user monitor "$MONITOR_PASS"
rabbitmqctl set_user_tags monitor monitoring

For anything that writes — applying a policy, creating a user, syncing definitions — make it safe to re-run by checking current state first and using the API’s idempotent PUT semantics. And give the script a dry-run mode:

Add a —dry-run flag to this script that prints the exact PUT requests it would make and the current state of each object, without sending any writes, so I can review the diff before applying to production.

That dry-run-then-verify pattern is what makes a bulk operation auditable instead of a leap of faith.

Where AI gets the management API wrong

The recurring overreach is treating every endpoint as equivalent and the broker as infinitely pollable. AI will cheerfully suggest a five-second poll across all queues because, functionally, it works — until the cluster grows. When it hands me a polling script, I ask: “What does this cost on a cluster with five thousand queues at this interval?” If it can’t reason about the per-queue stats computation, the interval is a guess.

The other gap is auth. Models default to admin credentials in examples because that’s what’s in the docs, and they rarely volunteer the monitoring tag or warn against embedding credentials. I always make the read-only user explicit and pull secrets from the environment, not the script.

My automation loop

I tell the AI what I need to know, force it to pick the cheapest endpoint that answers it, and make it add column filters and a sane interval. I run the script with a dedicated monitoring user against a staging broker that has a realistic queue count, and I watch the broker’s own CPU and the management node’s load while the script runs — if the automation shows up in those graphs, the interval or the columns are wrong. For writes, dry-run first, verify each change after. The AI writes the script; the staging broker’s load graph tells me whether it’s a good citizen.

This pairs naturally with queue investigation workflows, since the API is how you’d automate the checks you’d otherwise run by hand. The broader RabbitMQ category covers the operational topics these scripts tend to touch, and the automation prompts I use live with my other prompts.