Your #alerts Channel Isn't a Feed. So I Built One.

Every team I work with has the channel. It's called #alerts or #events or #bot-spam, and everybody muted it months ago.

It starts with good intentions. Someone wires up a webhook so new signups post to Slack. Then deploys. Then failed payments, cron jobs, errors, the waitlist form. A year later the channel scrolls faster than anyone can read it, and the one message that mattered last night is buried between 40 that didn't.

I had the same problem across my own products. I wanted to see what was happening in all of them (signups, deploys, errors, sales) without shipping that data to a third-party analytics service. Everything I tried was either too complex, too expensive, or both. So I built Get Butters.

Chat is the wrong shape for events

Slack is built for conversation. Events aren't conversation, and that mismatch shows up in 4 places.

You can't find anything. Finding last night's failed deploy means scrolling. There's no filter for category, tag or date.

There are no numbers. A channel can tell you a signup happened. It can't tell you how many happened this week, or show you the trend.

Everything shares one stream. Your side project's waitlist signups sit right next to production errors, at the same volume.

Everything is equally loud. A routine cron success gets the same treatment as a payment failure, so people mute the lot.

None of this means Slack is bad. It means Slack should get the handful of events worth interrupting someone for, and the full record should live somewhere built for it.

One request in, one feed out

The core of Get Butters is a single HTTP POST: a title, an optional emoji, a category and some tags. If your code can make a web request, it can tell you what just happened.

For anything that can't hold an API key, every project gets a secret webhook URL. curl -d "Backup finished" <your-url> is a whole integration. There's also a butters CLI for scripts, cron jobs and CI, and a browser SDK for tracking from the front end.

Events land in a live feed the second they happen. You filter by category, tag or date, search everything, and star the ones worth coming back to. Each app gets its own project, with its own feed and charts, so a side project stops drowning out production.

Only the important ones should make noise

The fix for a muted channel is fewer pings. Not better formatting, fewer pings.

In Get Butters, an event only notifies anyone if you mark it notify. Those go out as native browser and phone push (no app to install), to your own ntfy topic, or to Slack, Discord or a signed webhook. Everything else stays in the feed, where you can find it when you need it.

So Slack still gets messages, just the ones a person should actually see.

Counting, not just logging

The other thing a chat channel can't do is keep score. Get Butters has KPI cards you update with the same kind of call: send a title and a value, and the card for users online, MRR or queue depth stays current. Charts show event volume by category over time.

That covers the "how are we doing" question for a lot of small products, without standing up a full analytics stack.

Your data stays yours

This was the point of building it. You can export your projects, events and insight cards as JSON whenever you like, and import or merge them back. No hostage data.

It also speaks MCP, so an AI agent can send events, read charts and set insights directly. If you're running agents on real work, a feed of what they did is exactly the kind of record you want somewhere other than a chat log.

What people send

If you're wondering where to start, these are the usual first events:

• Product events. "🎉 New signup · pro trial."
• Deploys and CI. "🚀 Deploy finished · main@b26c900."
• Payments. "💳 Payment succeeded · $49 · Pro", and the failed charges, marked notify.
• Errors. The exception, the route and the user, with a ping only for the ones that cost money.
• Cron jobs. Log every run, so you notice when "🧾 Nightly invoices · 212 sent" doesn't show up.

That last one is where it's heading next. The public roadmap includes absence alerts: tell me when a backup event hasn't arrived in 25 hours. It's a dead-man's switch for the jobs that fail quietly, and it's the feature I want most myself.

Try it

Get Butters is a bootstrapped indie product, and I build and run it myself. There's a free plan, and the first event takes a couple of minutes to send. If you email support, I'm the one who answers.

Unmute your alerts channel for a day and count the messages. If most of them didn't need a human, they need a feed.