Your pager buzzes. Dead letter queue spike. Again.
If you’ve spent any serious time with Azure Service Bus, you know the drill. The Portal shows you a count—“5,000 messages”—and absolutely nothing else. No message content. No error details. No clue why things broke. Just a number mocking you while you scramble to figure out what’s happening in production.
That’s the exact frustration that led one developer to build ServiceHub, a free web-based tool designed to do what Microsoft’s own interface should’ve done years ago: actually let you see what’s in your dead letter queues.
Why Azure Service Bus Debugging Is Still Broken
Look, Azure is a solid platform. But the Service Bus Portal experience is stuck in 2015. You get metrics. You get counts. You get a vague sense that something is wrong. What you don’t get is visibility.
The dead letter queue exists for a reason—it’s where messages go when they fail. But there’s no built-in way to inspect them without writing custom code. No batch operations. No replay functionality. No way to understand patterns in your failures without exporting data somewhere and analyzing it yourself.
And when you’re woken up at 2 AM because your message pipeline is backing up, the last thing you want to do is spin up a console app and write queries.
What ServiceHub Actually Does (Beyond the Marketing)
The tool lets you paste your Service Bus connection string into a web interface—it only needs Listen permission, not full access, which is a smart security design choice—and suddenly you can see what the Portal refuses to show you.
“See the full message content (JSON body, properties, headers) that the Portal hides.”
That’s the core feature. It’s not flashy. It’s not AI-powered (well, there’s some client-side pattern detection, but more on that later). It’s just useful.
The feature set beyond that includes:
- DLQ Intelligence: History, failure categorization, timeline view. You can actually understand why messages are failing, not just that they are.
- Batch replay: Safely re-queue failed messages without manually processing each one. This alone saves hours on incident response.
- Correlation Explorer: Trace a message’s complete journey through your system. Finally, you can connect the dots.
- Scheduled delivery: Control when messages get replayed back into your queue.
- Export functionality: Get your data out if you need to analyze it elsewhere.
It’s lean. It doesn’t try to do everything. It focuses on the thing Azure Service Bus users actually need: visibility and control over dead letter queues.
The Real Question: Will Anyone Actually Use This?
Here’s where I get cynical. There’s a long history of developers building tools to solve their own pain points, deploying them for free, and watching adoption flatline because:
- Organizations already have custom solutions (even if they’re terrible)
- Security teams won’t approve connecting to production via a random GitHub project
- The person who built it gets hired elsewhere and stops maintaining it
ServiceHub addresses the security concern reasonably well—it’s client-side, needs minimal permissions, and the code is on GitHub so teams can self-host if they want. And deployment is dead simple: git clone, ./run.sh, done.
But adoption still depends on word-of-mouth. Azure teams aren’t scouring GitHub for Service Bus tools. They’re either suffering through the Portal, building their own solution, or using some enterprise monitoring platform.
Why This Matters (And Why It’s Kind of Indicting)
The existence of ServiceHub is a small indictment of Microsoft’s Azure Portal. This is table-stakes functionality. Microsoft charges thousands of dollars for Azure expertise and enterprise support. They could bake this into the Portal tomorrow.
But they haven’t. And won’t, probably. Because the Portal isn’t a revenue center. It’s a support cost. Azure’s money comes from the compute hours and data transfer, not from the UX of managing queues.
So an individual developer fills the gap. They don’t charge for it. They get maybe a GitHub star or two. And Microsoft continues treating the Service Bus Portal like it’s a 2010 product.
This is actually a pattern in enterprise software: tools get built because vendors deliberately underinvest in UX as a way to drive services and consulting revenue. So the community builds what should’ve existed anyway.
Who Should Care (And Who Probably Won’t)
If you’re running any non-trivial message queue setup on Azure, ServiceHub should be in your toolkit. Particularly if you’re on-call and don’t want to write C# code at 3 AM to debug a production incident.
But—and this is important—adoption will be strongest among:
- Small to mid-size teams that can’t afford to roll their own monitoring solution
- Orgs with DevOps-first cultures that embrace tools from the community
- Teams already using Azure but frustrated with the Portal
Enterprise shops with procurement processes? They’ll probably build their own version in-house because it’s easier than approving a GitHub project.
The Open Source Math
ServiceHub is free and open source. The creator isn’t monetizing it. They’re not selling a SaaS version (though they’re hosting a demo). This is pure community contribution—someone scratching their own itch and sharing the solution.
Which is great for users. Which is also why sustainability questions linger. The maintainer will probably move on eventually. Whether ServiceHub becomes a community project with multiple contributors, or slowly rots, depends on whether it gains enough traction to attract other people who care.
🧬 Related Insights
- Read more: The Silent Killer of On-Call Engineers: Why Your Monitoring Is Broken
- Read more: Build Your Own AI Trading Agent: The $44 Billion Opportunity Crypto Developers Are Missing
Frequently Asked Questions
Is ServiceHub secure to use with production connection strings?
It only requires Listen permissions (not Manage), which limits what an attacker could do even if they had your connection string. The code is open source so you can audit it. The demo is hosted by the creator, but you can also self-host it on your own infrastructure if you’re paranoid.
Can I replay messages back into my queue without losing them?
Yes. ServiceHub has built-in safeguards for batch replay and scheduled delivery, so you can test a replay strategy before committing. This is basically what you’re paying consultants thousands to write custom code for.
Will this replace Azure’s built-in monitoring?
No. This is specifically for dead letter queue inspection and message replay. For broader metrics, alerting, and system health, you still need Application Insights or Log Analytics. But for “my queue is broken, let me see why,” ServiceHub does what the Portal should’ve done five years ago.
