I built an MQTT 5 client because I wanted to understand traffic, not just see payloads
I’ve been working on an open-source MQTT client called Crow’s NestMQTT.
The thing that originally bothered me with MQTT debugging was that receiving messages is easy … understanding what’s actually happening across a larger broker is not. Especially when you have hundreds/thousands of topics, MQTT 5 metadata, request/response flows, binary payloads and a few very noisy telemetry topics.
So Crow’s NestMQTT has gradually turned into more of an MQTT 5 workbench than a simple pub/sub client. Some of the things I find particularly useful now:
- Topic tree + per-topic message history
- MQTT 5 metadata including response-topic,
correlation-data, content-type, user properties, expiry, etc.
- Automatic linking of MQTT 5 request → response using correlation data
- content-type aware viewers for JSON, images, video and binary/hex payloads
- Per-topic ring buffers, so one high-frequency topic doesn’t evict everything else
- Per-topic traffic statistics (:stats) for message count, payload size and message interval
- Publishing messages with MQTT 5 properties
- Search/filtering and Vim-inspired keyboard navigation
- TCP, WebSockets, TLS and MQTT 5 enhanced authentication
- Windows, Linux and macOS
It’s open source:
https://github.com/koepalex/Crow-s-Nest-MQTT
I also wrote up a few concrete scenarios showing how I use it when exploring an unknown MQTT system or debugging MQTT 5 request/response:
https://www.alexander-koepke.de/post/2026-09-30_crows-nestmqtt-scenarios/
I’m curious how other people here debug larger MQTT systems.
What is the thing your current MQTT client makes unnecessarily difficult?
I’d especially be interested in features/workflows that become painful once you’re dealing with a real system rather than a handful of test topics.
Feedback, criticism and feature ideas are very welcome.