Hey everyone! Just saw the announcement about Humata's new Slack integration. As someone who lives in Grafana and PagerDuty all day, I'm always skeptical about new "integrations." Are they actually useful for the team's workflow, or just a feature checkbox on a sales sheet? 🤔
I can imagine a few potential uses, but I want to hear from anyone who's tried it. For example:
* Are the alerts actionable? Can I triage from Slack, or is it just a notification that forces me to open Humata anyway?
* What's the configuration like? Can I route specific query alerts to specific channels? Is there granular control?
* Most importantly: does it reduce context-switching, or does it just add another noisy channel to monitor?
If you've set it up, what's your verdict? Share your config approach if you can! I'm especially curious about filtering and priority settings. A useless alert stream is worse than no integration at all.
If it's not monitored, it's broken.
Great questions. I've been running it for a week now, and my verdict is mixed.
The alerts themselves are notifications, not fully actionable in Slack. You get a link back to the query result in Humata, but you can't run remediation or even acknowledge from the Slack message. That's a missed opportunity compared to PagerDuty.
The configuration is surprisingly decent, though. You can route based on query tags or even result values. I set up a rule to only post to our `#data-alerts` channel if the query returns a count over a specific threshold, which cuts down on noise.
It hasn't reduced my context-switching much yet. It just moved the notification pane. If they added interactive buttons or the ability to trigger a runbook from the alert, it'd be a game changer. For now, it feels more like that checkbox.
That point about it just moving the notification pane is exactly right. I see teams make this mistake all the time. They think adding a Slack integration *is* the workflow improvement, when all they've done is shift the cognitive load from one tab to another. Real integration reduces steps, it doesn't just change the delivery mechanism.
Your config example using result values to filter noise is the only part that seems mildly useful. Without that, it's pure spam. But if I still have to click through to Humata to do anything about it, the workflow is fundamentally broken. It's a glorified RSS feed.
I'd argue if your goal is to reduce context-switching, this fails the test. The metric is simple: did the number of clicks or app toggles required to resolve an alert go down? In this case, it sounds like it stayed the same or maybe even increased. That's a fail in my book, decent routing rules or not.
test in prod, but only on Thursdays
Exactly the right questions to ask. Every time I see a "NEW INTEGRATION!" headline, my eyes roll so hard. It's usually just a webhook wrapper they spent a sprint on so the sales team can tick a box.
My rule of thumb: if you can't *do* something meaningful from the notification (mute, acknowledge, run a playbook), it's not an integration. It's a fancy ping. And from what user383 said, it sounds like Humata's falls squarely in the "fancy ping" category.
You're right to focus on context-switching. If I'm already in Grafana/Loki for 90% of my day, getting a Slack alert that forces me back into Humata is a net negative. I've seen teams drown in these well-intentioned notification streams.
Open source is the answer