Why we built ML signal classification into Monitr

The noise problem nobody talks about

When you're watching App Store reviews, Google Play reviews, Twitter, Reddit, and Google News all at once, you get a lot of information. Mostly rubbish.

A user on Reddit complains about the app being slow. That's actionable. Someone on Twitter says your app icon looks nice. Also real feedback, but not urgent. A news outlet covers a competitor's outage and mentions your app's name in passing. Technically a mention, but worthless without context.

The studios we spoke to early on were drowning in it. They'd built notification systems that sent every ping to Slack. Within weeks, they'd muted the channels or stopped checking them. We'd solved the discovery problem. We'd created the noise problem instead.

Classification is where signals become actionable

That's when we decided classification had to be built in from the ground up, not bolted on later.

Every mention that comes into Monitr gets tagged as one of five things: bug_report, feature_request, pr_crisis, positive_feedback, or noise. The classification happens the moment we see it. Not hours later. Not when you get around to reading your digest.

A bug report goes to your engineering channel in Slack or straight to Linear. A feature request lands in your product backlog. A PR crisis triggers an alert every fifteen minutes until you've marked it handled. Positive feedback goes somewhere useful instead of disappearing into an unmuted Slack thread nobody reads.

The noise still gets logged. But it doesn't scream for your attention.

Why hourly correlation matters more than you'd think

Classification alone would be half the story. The other half is connecting the dots.

An hour after you ship a payment flow change, you might get a bug report on the App Store. Twenty minutes later, someone on Reddit mentions the same issue. An hour after that, Twitter picks it up. Without correlation, you see three separate incidents. With it, you see one problem with three data points.

Monitr groups related signals into narratives every hour. Not because we're obsessed with batching. Because a founder at 2am needs to know whether she's dealing with one real issue or five unrelated complaints. The difference between those two things is whether she needs to wake up her engineer or check her notes in the morning.

Routing stops being a manual game

Once you know what a signal is and whether it's connected to something else, where it goes becomes obvious. Almost.

We let you write rules. If a signal is tagged as bug_report and mentions performance, send it to your iOS team's Slack channel. If it's a feature_request with more than five correlated mentions in a week, post it to GitHub Issues. If it's pr_crisis, trigger a crisis alert and paste it into the Linear board your head of operations watches.

You can route to Slack, Linear, Jira, GitHub Issues, Trackr, or Shpd. The point isn't that we support six destinations. It's that you're not manually triaging anymore. Your signal goes where it's useful the moment it arrives.

The constraint that made it real

We could have built a system that shows you everything and lets you search later. Most monitoring tools work that way. It's easier to build. It's cheaper to run. It looks impressive in a demo because you can show every mention ever.

We chose the harder path because watching five sources at scale makes raw volume a liability, not an asset. A studio managing five apps gets thousands of mentions a month. If you're on our Pro plan, that's fifty thousand. You're not going to read fifty thousand items. You're going to check Slack and see what's routed there.

So the question became: how do we make sure what's routed to you is worth your time? The answer was classification with teeth. Not a checkbox feature. Not a nice to have. Core to how the system works.