Not everyone on your team needs to see every event. Your designer doesn't need subscription renewal noise. Your finance person doesn't need crash logs. Your QA lead doesn't need revenue alerts at 2am.
Yeethook lets you route events to the right Slack channels so the right people see the right things.
How routing works
Every app you add to Yeethook can connect to one or more Slack channels. For each connection, you choose which event types to forward. If you don't filter, everything goes to that channel. If you do, only the event types you pick show up.
You can connect the same channel to multiple apps, or spread one app's events across several channels. The combinations are flexible.
Four common setups
Single channel
Connect all your apps to one Slack channel. Every event lands in the same place.
This works well for solo developers or small teams with one or two apps. Simple, no configuration overhead, and you see everything at a glance.
By concern
Route events by what they mean to your team:
- Crash reports and TestFlight feedback to #bugs. The QA team and developers see crashes and tester screenshots the moment they happen.
- App review status changes and build processing to #releases. The team tracking your release pipeline sees submissions, approvals, and rejections.
- Subscription events (renewals, cancellations, refunds) to #revenue. The people watching the business metrics see subscriber activity in real time.
- Churn signals (
DID_CHANGE_RENEWAL_STATUS) to #churn. The earliest warning that a subscriber turned off auto-renew, delivered to the team that can do something about it.
This setup keeps channels focused. When you open #bugs, it's all quality issues. When you open #revenue, it's all subscriber activity. No noise from the wrong category.
By app
Give each app its own channel. #myapp-events, #otherapp-events, etc.
This is useful when different teams own different apps. The team shipping a productivity app doesn't need to see crash reports from the game your other team is building. Each team gets their own channel with only their events.
Hybrid
Combine the approaches. Route crash reports from all apps to a shared #bugs channel (so the QA team sees everything), but give each app its own channel for everything else.
Or route subscription events from all apps to #revenue but keep build and review events per-app. Whatever matches how your team actually works.
Bulk operations
When you add a new Slack channel (say #crashes), you can connect it to multiple apps at once. Pick the channel, select the apps, choose the event types, done. No need to set up each connection one by one.
This is especially handy when you have a lot of apps. If you're managing ten apps and want crash reports from all of them in one place, bulk operations save you from ten rounds of configuration.
What it looks like in the dashboard
The dashboard shows your apps, the event types each one is configured for, and the Slack channels connected to each app. You can add or remove connections, change event type filters, and see delivery status from one place.
If you're not sure where an event type is going, the dashboard tells you. If you want to change it, it takes a few clicks.
Start simple, refine later
You don't need the perfect routing setup on day one. Start with a single channel. See what the event volume looks like. Notice which events you care about and which are noise for that particular audience.
Then split. Move crashes to their own channel. Give subscriptions their own channel. Add per-app channels when your team grows. Routing is something you refine over time as you learn what works for your team.
The goal is simple: right events, right channels, right teams.