QueueForge

QueueForge is a self-hosted platform for watching, inspecting and recovering failed messages in RabbitMQ and Kafka. It ships as two products, DLQ Manager for RabbitMQ dead letter queues and Kafka DLT Manager for Kafka dead letter topics, and each gives you a dashboard that shows where a failed message came from, why it landed where it did, and what to do with it next. Dead letter queues are where RabbitMQ parks messages that were rejected, expired or exceeded their retries, and Kafka dead letter topics play the same role for records that failed processing, schema validation or deserialization. The problem QueueForge goes after is the black box those queues tend to become. A message fails, then sits somewhere nobody looks until a customer notices something missing. Its position is that you shouldn't have to tail logs and guess routing keys to find out what happened.

You connect a RabbitMQ cluster or a Kafka broker by providing a connection string, and the dashboard fills with live metrics and the routing journey of each message. From there you open a failed message, inspect its payload, headers, routing details and retry metadata, and either send it back to its original destination, reroute it somewhere else, or delete it if the data really is dead. The alerting covers the signals that usually come before an incident, including a queue passing a message count you define, a queue growing too fast inside a short window, consumers that are connected but not acknowledging, messages that stay unacknowledged for too long, and retries that keep failing. Notifications go out through Slack, Telegram and Discord.

The part the team calls its killer feature is a rule engine that turns those signals into automation. You build a scenario per queue, for example if the error count reaches three within five minutes then reroute the message to an alternative exchange, and QueueForge runs it without anyone watching the screen. It also monitors ordinary queues, not only dead letter ones, so the same size and growth alerts apply across the broker. The Kafka product adds consumer group lag monitoring and topic-to-topic replay of records once the underlying bug is fixed, and roughly the last two weeks of system logs can be downloaded as a zip for post-incident review.

It's built for backend engineers, DevOps teams, SREs and platform teams who run RabbitMQ or Kafka in production and are tired of recovering messages by hand. Microservice estates are the obvious fit, since a failure in one service tends to surface as a dead letter in another, and the product gives one central place to inspect failures and spot growth patterns across services. The two founders, Nurlan Amrahov and Anar Karimov, come from banking and enterprise systems work and build the product from Baku, Azerbaijan, on a Java and Spring Boot core with a React and Next.js front end. Support goes straight to the engineers who wrote the code, which is a real advantage for a small team and a fair question for a large organisation that expects tiered support.

What sets it apart from a broker's own management UI is the focus on recovery rather than visibility alone. A management plugin will show you a queue depth. QueueForge shows you the message, lets you edit and replay it, and can do that on its own under a rule you wrote. Being self-hosted matters too. The FAQ is explicit that the platform runs inside your own infrastructure and security boundary, and licences are activated per instance from inside the app, with a trial licence requested by email and a paid key entered after purchase.

The limits are worth knowing before you sign up. It covers RabbitMQ and Kafka and nothing else, so teams on other brokers are out of scope. There's no permanent free tier, only the six-day trial, which is enough to connect a real cluster and see the routing view but not to leave it running for a month. And because it's a young product from a two-person team, the documentation is still filling in, with the installation guide noticeably shorter than the FAQ at the time of writing. Against that, the flat price is low enough that it competes with the cost of a single afternoon of debugging, which is exactly the comparison the pricing page makes.

Pricing is flat rather than per message or per queue. A six-day trial unlocks every feature with no credit card, and when it ends the account pauses with settings, rules and connection configs kept until you upgrade. Premium costs $9 a month or $90 a year, which works out to two months free, and the price is the same whether you connect one cluster or fifty. The RabbitMQ and Kafka managers are separate products with independent subscriptions, so a team running both pays for each. Docs cover installation, licence activation, configuration, troubleshooting and a long FAQ, and the site describes a small engineering team answering support directly rather than a ticket queue.