Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: RobinRelay – Slack-native memory layer for noisy alerts

robinrelay.ai

Post reply on HN
Print view View original

1–6 of 6 posts

Show HN: RobinRelay – Slack-native memory layer for noisy alerts

#1

Post by alibasharat5 »

Hi amazing community,

I’m Ali a solo founder and ex-SRE. After working at Dynatrace and Gartner, I left my job to build RobinRelay, a Slack-native assistant for noisy alerts and incident memory.

The Problem: SRE and DevOps teams get flooded with alerts in Slack. People investigate in threads or the main alert channel… and then the context disappears.

So when the same alert happens again (next week, another team, different cluster), everyone starts from scratch.

What I’ve Built: RobinRelay watches your alert channels and automatically replies when a recurring alert is detected. It brings back:

Past thread replies: Root cause + fix summaries Cross-channel memory (Team A solves it, Team B sees it next time) We’ve also added Slack-native dashboards like:

- Alert heatmaps to show noisy days - Insights directly inside the Slack App Home tab — no need to leave Slack

RobinRelay runs in one company across 3 live Datadog alert channels and delivers context in under a minute.

About Integrations: No rigid setups. RobinRelay listens directly to Slack channels and automatically parses any alert format using LLMs, including custom bots. That means unlimited integration possibilities without any API keys, webhook configs, or vendor lock-in.

Seamless Setup: Install the app Choose the alert channel RobinRelay starts reading historical alerts + discussions to surface useful memory and insights — no manual migration needed. Demo (1:40) YouTube: https://www.youtube.com/watch?v=RSY7-AZJqU8

Or join the public demo workspace to see it live: https://join.slack.com/t/robinrelay/shared_invite/zt-39kf33n...

Looking For Feedback from teams who:

Handle alerts in Slack Run on-call rotations Care about reducing alert fatigue and rework I’m happy to answer questions or ship improvements based on feedback!

Show HN: RobinRelay – Slack-native memory layer for noisy alerts
robinrelay.ai

Re: Show HN: RobinRelay – Slack-native memory layer for noisy alerts

#2

Post by alibasharat5 »

Thanks for checking it out! Tech-wise: RobinRelay is built using Slack Events API + Supabase for alert history and AI Agents. We wanted to avoid building another dashboard. So the product works entirely in Slackfrom setup to insights to summaries. Would love to hear how your teams manage alert noise and if memory around incident history would be useful to you.

Re: Show HN: RobinRelay – Slack-native memory layer for noisy alerts

#3

Post by louiscb »

Nice, so as I understand the tool gets it information about the alert from the alert messages itself? What if there is more relevant information hidden within the provider e.g Datadog. Alerts have been a huge cause of pain at every job I've had so good to see solutions coming out in this space.

Re: Show HN: RobinRelay – Slack-native memory layer for noisy alerts

#4

Post by alibasharat5 »

louiscb wrote: post #3

Nice, so as I understand the tool gets it information about the alert from the alert messages itself? What if there is more relevant information hidden within the provider e.g Datadog. Alerts have been a huge cause of pain at every job I've had so good to see solutions coming out in this space.

Thanks, Yes, Exactl! RobinRelay reads directly from the Slack alert messages (from monitoring tools, custom bots, etc.) and builds memory from the messages and thread discussions around them or even discussions in the channel itself (not in thread) we build Semantic matcher algorithm to connect message with the alert..

The goal was to avoid needing any API keys or deep integrations - just install, select the alert channel, and it starts working by parsing alert messages and mapping patterns.

You’re totally right though, there is richer metadata inside tools like Datadog. But we think end users have better context of known issues, but we're intentionally starting frictionless and will expand further to provide insights on newly seen incidents and use API to pull all the data.

Glad to hear you’ve felt the pain too... that’s exactly why I built this!

Re: Show HN: RobinRelay – Slack-native memory layer for noisy alerts

#5

Post by gujjar19 »

This is such a well-executed idea, Ali, the "context loss" problem during incident response is very real and painful. Love how RobinRelay bridges historical discussions across teams within Slack itself — no new dashboards to log into, and no brittle integrations needed.

A few things I’d love to hear more about:

How does RobinRelay handle conflicting advice or noisy past threads?

Can it differentiate between alert variants (e.g., same service but different error codes)?

Any future plans to surface trends like “this alert usually precedes X outage”?

For teams drowning in alerts and Slack chaos, this looks like game changer

Re: Show HN: RobinRelay – Slack-native memory layer for noisy alerts

#6

Post by alibasharat5 »

gujjar19 wrote: post #5

This is such a well-executed idea, Ali, the "context loss" problem during incident response is very real and painful. Love how RobinRelay bridges historical discussions across teams within Slack itself — no new dashboards to log into, and no brittle integrations needed. A few things I’d love to hear more about: How does RobinRelay handle conflicting advice or noisy past threads? Can it differentiate between alert var…

Thank you so much really appreciate the kind words... You are right.Context loss during incident response is the problem we’re aiming to solve deeply, especially for teams that live in Slack and don’t want to chase dashboards.

Let me try to answer your great questions:

1. Conflicting advice or noisy threads: Right now, RobinRelay summarizes past replies per alert occurrence (thread), then aggregates them across all past occurrences of the same (e.g., “CPU spike on api-server”). If conflicting advice exists (e.g., restart vs scale up), we preserve each cause separately and display them like:

“In the past, this alert was caused by: – autoscaler OOM restart (3x) – DB connection saturation (2x)” We’re working on tagging which ones were “confirmed fixes” vs just investigative noise and will open that to user feedback soon.

Alert variants: We normalize alerts our algorithm similar to finger prints for vector db. We’re exploring multiple ways like fuzzy hashing, LLM's, custom way to detect meaningful variants (e.g., same service, different root cause) and eventually flag them as “related but distinct”.

Trend detection (e.g. precursor alerts): Yes! This is on our roadmap. We want to show timelines like:

If you're seeing these pain points first-hand, I’d love to chat or hear how your team handles it today — this kind of feedback shapes the product every week.

Thanks again for the thoughtful comment

Post reply on HN