Hi everyone.
I’m facing an issue with my n8n after migrating from version 1 to version 2. Almost everything went as expected, following the documentation and materials recommended by the n8n team itself.
However, only the RabbitMQ Trigger is not working in production. I’m currently using the n8nio/n8n:2.20.11 version.
All other services and workflows are functioning correctly. I’ve already checked the container logs and there are no error messages related to RabbitMQ or n8n.
Has anyone experienced a similar situation or do you have any suggestions on what I can check to diagnose the problem?
{
“nodes”: [
{
“parameters”: {
“queue”: “events_gtm_site”,
“options”: {
“acknowledge”: “executionFinishesSuccessfully”,
“jsonParseBody”: true,
“parallelMessages”: 1
}
},
“type”: “n8n-nodes-base.rabbitmqTrigger”,
“typeVersion”: 1,
“position”: [
-512,
-96
],
“id”: “6d7f1ff1-9a21-47fe-89ae-4061c7511aaf”,
“name”: “RabbitMQ Trigger”,
“credentials”: {
“rabbitmq”: {
“id”: “wVrj5UEs25xLJdEq”,
“name”: “fila.dev”
}
}
}
],
“connections”: {
“RabbitMQ Trigger”: {
“main”: [
]
}
},
“pinData”: {},
“meta”: {
“templateCredsSetupCompleted”: true,
“instanceId”: “f0cbe7498a9883f06a79ac843439c264423cb24ac37f469eff9523a6464b2b62”
}
}
My production environment consists of a Debian machine running all services in Docker containers. I’m currently using the n8nio/n8n:2.20.11 version of n8n.
@Gustavocostadev with 2.x’s publish/unpublish model, just importing the workflow doesnt automatically register the RabbitMQ listener — needs an explicit publish to attach to the queue. is the workflow showing as Published in the UI? and if u tail n8n’s container logs (docker logs -f n8n) right when a message lands in ur queue, does anything fire at all or total silence?
Hi @Gustavocostadev
Since you aren’t seeing any error messages in your logs, the problem is likely a “silent failure.” This means n8n might be connected to RabbitMQ, but it isn’t actually “listening” to the specific queue, or the messages are being intercepted by something else. The goal is to figure out if the communication gap is happening inside n8n or inside the RabbitMQ server itself.
The most important first step is to check your RabbitMQ Management dashboard. You need to see if n8n is actually listed as a “consumer” on your specific queue. If it doesn’t appear there, n8n has failed to ask for messages, which usually points to a permission issue or a configuration error. If it does appear as a consumer but no workflows are running, you might have an old version of n8n still running in the background that is “stealing” the messages before the new version can get them.
You also need to check how your n8n is structured. If you are using a professional “Queue Mode” setup with multiple workers, remember that the “Main” n8n instance is the one responsible for listening to triggers. If the Main instance has a network issue or lacks the correct permissions to access the specific RabbitMQ “vhost” (the virtual folder where your queue lives), the workers will never receive any instructions to start a workflow, even if the workers themselves are working perfectly.
To resolve this, try turning on “debug” mode in your n8n settings to reveal the hidden technical details that are currently being skipped in your standard logs. Additionally, because you just migrated from version 1, try recreating the RabbitMQ credentials and the trigger node from scratch. Migration processes can sometimes carry over “ghost” settings from the old version that prevent the new version from functioning correctly, even if the setup looks perfect on the screen.