RabbitMQ

Connect a RabbitMQ broker so CloudThinker can tell you which queues are backing up, which have no consumers, what’s sitting in your dead-letter queues, and whether any node is in alarm. The connection signs in with a broker username and password over the Management HTTP API, the same API the RabbitMQ management UI uses. You don’t need a code change.

Supported platforms

Platform	Supported	Notes
Self-hosted RabbitMQ	Yes	The `rabbitmq_management` plugin must be enabled
Managed RabbitMQ (for example CloudAMQP)	Yes	The provider must expose the Management HTTP API to CloudThinker
Clusters	Yes	Add one connection per cluster. Point RABBITMQ_HOST at a load balancer or any node: the management API reports cluster-wide state from any node

Prerequisites

The management plugin enabled on the broker.
The management port reachable from the internet: 15672 for HTTP, usually 15671 for HTTPS. This is a different port from AMQP (5672). Connections run from CloudThinker Cloud, so a broker on a private network needs one of the options in Reaching private services.
Shell access to the broker (rabbitmqctl), or your provider’s console, to create a user.

Setup

Enable the management plugin

On a self-hosted broker, run:

rabbitmq-plugins enable rabbitmq_management

Managed providers usually have it on already. Skip this step if your provider’s console shows a management UI.

Create a monitoring user for CloudThinker

Create a dedicated user, tag it monitoring, and give it read permission on each virtual host (vhost) agents should see. A vhost is RabbitMQ’s namespace for queues and exchanges; / is the default one.

rabbitmqctl add_user cloudthinker '<strong-password>'
rabbitmqctl set_user_tags cloudthinker monitoring
rabbitmqctl set_permissions -p / cloudthinker "" "" ".*"

The three permission strings are configure, write, and read. Empty configure and write with .* read lets the user see everything in the vhost, but it isn’t fully read-only: RabbitMQ lets read permission purge a queue, so this user can still empty one. Deleting queues and exchanges needs configure, which it doesn’t have. Repeat set_permissions for each extra vhost.To keep agents from purging anything, set RABBITMQ_ALLOW_MUTATIONS to Read-only in the next steps.

Open the network path

Allow inbound traffic from CloudThinker’s egress IPs to <host>:15672 (or your TLS management port) in your firewall or security group. These docs don’t publish CloudThinker’s egress IP list: ask your CloudThinker contact, or contact us. On self-hosted brokers, make sure the management listener isn’t bound only to 127.0.0.1.Success state: run this from a machine outside the broker’s network. It returns JSON with rabbitmq_version and cluster_name, which proves both the new user and the network path:

curl -u cloudthinker:'<strong-password>' http://<host>:15672/api/overview

With TLS on, use https://<host>:15671 instead.

Add the connection in CloudThinker

In the sidebar, click More → Workspace settings → Connections, stay on the Builtin Connections tab, and select RabbitMQ. Fill in:

RABBITMQ_USERNAME: cloudthinker
RABBITMQ_PASSWORD: the password you set
RABBITMQ_HOST: hostname or IP only, such as rabbit.internal.example.com
RABBITMQ_MANAGEMENT_PORT: 15672, or your TLS management port
RABBITMQ_USE_TLS: Enabled if the management API serves HTTPS
RABBITMQ_ALLOW_MUTATIONS: Read-only (recommended). Pick Allow writes only if you need the actions in Write access
LOG_LEVEL: leave at Info

RABBITMQ_ALLOW_MUTATIONS defaults to Allow writes. Switch it to Read-only before you click Connect. The broker user doesn’t stop every write on its own: a user with only read permission can still purge a queue, and a purge deletes its messages for good. Read-only keeps the purge and delete tools away from agents.

Click Connect.Success state: the connection shows Connecting and Verifying, then Connected. If verification fails, it shows Failed and an error message appears. Match the message to Troubleshooting.

Connection details

Field	Required	Default	Description
RABBITMQ_USERNAME	Yes	None	Broker user with the `monitoring` tag
RABBITMQ_PASSWORD	Yes	None	That user’s password
RABBITMQ_HOST	Yes	None	Hostname or IP. No `http://`, no `https://`, no port
RABBITMQ_MANAGEMENT_PORT	Yes	`15672`	Management HTTP API port. Use your TLS port (usually `15671`) with TLS on
RABBITMQ_USE_TLS	No	Disabled	Disabled: plain HTTP management API and AMQP. Enabled: HTTPS management API and AMQPS
RABBITMQ_ALLOW_MUTATIONS	No	Allow writes	Read-only (recommended): monitoring and troubleshooting only. Allow writes: enables purge, delete, and bulk definition updates, each checked by your Approvals one by one
LOG_LEVEL	No	Info	Connector log detail: Debug, Info, Warn, or Error

Required permissions

Goal	User tag	vhost permissions
Monitoring and troubleshooting (recommended, with Read-only set)	`monitoring`	Read (`"" "" ".*"`) on each vhost agents should see. Read also allows purging a queue
Monitoring plus delete	`monitoring`	Configure and read on the vhosts agents may change
Bulk definition updates	`administrator`	Configure, write, and read. RabbitMQ only accepts definition imports from administrators, and that tag also grants user and policy management across the broker

Start with monitoring, read permission, and RABBITMQ_ALLOW_MUTATIONS set to Read-only. That covers every read capability below. Switch to Allow writes only when you’ve decided agents should purge or delete things, and add configure permission only on the vhosts where agents may delete. Use administrator only if you need bulk definition updates.

Agent capabilities

Capability	What agents can do
Queue depth and rates	Report messages ready and unacknowledged per queue, with publish and deliver rates
Consumer health	Find queues with no consumers, or where messages pile up faster than consumers drain them
Dead-letter review	Look inside dead-letter queues for repeated failures and the messages behind them
Cluster and node health	Check node status, memory and disk alarms, and quorum queues at risk of losing quorum
Certificate checks	Flag broker certificates close to expiry
Write actions	Purge or delete queues and exchanges, and apply bulk definition updates, only with Allow writes on and each one approved

Verify the connection

Show the RabbitMQ cluster status and list every queue with its depth and consumer count

Expect each node with its running state, then a table of queues with ready and unacknowledged counts and consumers per queue.

Example prompts

Which RabbitMQ queues have messages but zero consumers right now?
The orders queue keeps growing. Find out why and check its dead-letter queue for poison messages
Is any RabbitMQ node in a memory or disk alarm, and do any certificates expire in the next 30 days?

Write access

With RABBITMQ_ALLOW_MUTATIONS set to Allow writes and a user with the right vhost permissions (see Required permissions), agents can:

Purge a queue (drop every message in it)
Delete a queue or an exchange
Apply bulk updates to broker definitions (needs administrator)

Each one goes through Approvals on its own, and reads never need approval. Every change an agent makes goes through your workspace’s Approvals first. On the default Auto · Rules + AI · Ask me mode, AI judgment can let a safe change run without asking — and an Allow Rule can too, once CloudThinker turns on Rule enforcement for your workspace. Choose Manual to approve every change yourself. A purge needs only read permission on the queue, so the broker user won’t block one. If you turn writes on, choose Manual so a person approves every change — that is the control that works today. Once CloudThinker turns on Rule enforcement for your workspace, an Ask first Rule can narrow the wait to purges alone.

Purging or deleting a queue removes its messages for good. RabbitMQ keeps no copy. Check the queue name and vhost in the approval request before you approve.

Troubleshooting

Connection refused or timed out

Check that CloudThinker can reach <host>:15672 (or your TLS management port).
Make sure you opened the management port, not the AMQP port 5672.
On self-hosted brokers, confirm the management listener isn’t bound to 127.0.0.1 only.

404 Not Found from the management API

The management plugin is off. Run rabbitmq-plugins enable rabbitmq_management and connect again. On a managed broker, check that the provider exposes the Management HTTP API for your plan.

401 Unauthorized

Recheck the username and password.
Confirm the user has a management tag: rabbitmqctl set_user_tags cloudthinker monitoring. A user with no tag can sign in over AMQP but the management API rejects it.

TLS handshake or certificate errors

RABBITMQ_USE_TLS and RABBITMQ_MANAGEMENT_PORT must agree. Enabled needs the port that serves HTTPS (usually 15671). Disabled needs the plain HTTP port (usually 15672).

Host field errors

Put only the hostname or IP in RABBITMQ_HOST. Remove any http://, https://, path, or :port. TLS and port have their own fields.

Some queues or vhosts are missing

The user lacks read permission on those vhosts. Grant it with rabbitmqctl set_permissions -p <vhost> cloudthinker "" "" ".*", then ask again.

A purge or delete was refused

Either RABBITMQ_ALLOW_MUTATIONS is Read-only, or the broker user lacks the vhost permission the action needs: read for a purge, configure for a delete. Change whichever you meant to allow. The action still goes through your Approvals.

Security

Least privilege — grant only the permissions the agents need for your use case; start read-only and widen later.
Read-only by default — use read-only credentials unless you want agents to make changes through this connection.
Rotate credentials — rotate keys and tokens on your normal schedule; CloudThinker picks up the new value when you update the connection.
Revoke on offboarding — remove the credential at the provider when you delete a connection or a teammate leaves.

Use a dedicated user: create cloudthinker for this connection. Never reuse guest or a personal admin account.
Turn on TLS: with RABBITMQ_USE_TLS set to Enabled, the password and broker data are encrypted between CloudThinker and your broker.

Approvals

Decide which purges and deletes run, wait for a person, or are refused.

Kafka

Connect Kafka for topic health and consumer lag on your streaming side.

Connections

Customize

Approvals

Workspace settings

Admin Settings

Artifacts and sharing

Supported platforms

Prerequisites

Setup

Connection details

Required permissions

Agent capabilities

Verify the connection

Example prompts

Write access

Troubleshooting

Security

Approvals

Kafka

​Supported platforms

​Prerequisites

​Setup

​Connection details

​Required permissions

​Agent capabilities

​Verify the connection

​Example prompts

​Write access

​Troubleshooting

​Security

​Related

Approvals

Kafka

Supported platforms

Prerequisites

Setup

Connection details

Required permissions

Agent capabilities

Verify the connection

Example prompts

Write access

Troubleshooting

Security

Related