Why we built crisis alerts every 15 minutes

The problem with waiting for weekly digests

When we started Monitr, the natural temptation was to batch everything. Weekly digests are elegant. They're low noise. They're easy to implement. But a week is a lifetime when your app breaks in the morning.

The tension became real as we onboarded more studios. A SaaS founder told us she checked her App Store reviews religiously before coffee, five days a week. A brand manager at a consumer app said their team caught critical feedback at 9am and only saw it in their Monday digest. The lag felt absurd. Your customers are telling you something is broken. You're finding out four days later.

We realised the feature wasn't about giving people another notification. It was about closing the gap between when a crisis starts and when you can respond.

Why 15 minutes, not 5 or 60

The first instinct is always 'make it faster.' Give them alerts every minute. Every five minutes. But we tested something different: what's the actual window in which a team can act?

We looked at how our customers worked. Most studios don't have someone at their phone every second. But they do check Slack in bursts. Product managers context-switch between meetings. Developers look up between code reviews. Fifteen minutes is tight enough that you catch a crisis while options exist. Push a hotfix. Publish a statement. Start communicating before the story hardens.

Beyond that window, you're in damage control. Beneath it, you're generating noise for marginal value. Fifteen minutes felt like the breathing room where human teams could actually move.

It also meant we could correlate signals properly. In fifteen minutes, enough mentions of the same bug appear across Reddit, Twitter, and Google Play that our classifier can be confident it's real. Rushed faster, you'd alert on single posts. That's noise masquerading as speed.

What a 15-minute window actually catches

Our data shows most app crises announce themselves loudly in the first window. A bad update drops. Angry reviews flood in within minutes. Your mentions spike on Twitter. Reddit threads light up. By fifteen minutes, the pattern is unmistakable.

A studio building consumer tools discovered a payment issue that broke checkout on their most expensive tier. The crisis alert fired at 2:07pm, correlating three bug reports from Play Store, a Reddit post, and a burst of mentions on Twitter. Their team acknowledged it at 2:11pm, investigated at 2:14pm, and had a fix ready by 2:45pm. They pushed it live at 3pm. The damage was contained because they saw it while the problem was still fresh.

That same window catches feature requests that matter. A SaaS team noticed a cluster of mentions asking for dark mode. Not one person. Not ten scattered complaints over months. Five related signals, correlated within fifteen minutes, flagged as feature requests. That's when conversation starts. Not in a monthly retrospective.

It's also where you spot positive momentum. A redesign ships, and fifteen minutes later the alerts show genuine enthusiasm spreading across your audience. You see it happen. You can amplify it while it's warm.

The routing decision that followed

Once we committed to fifteen minute alerts, the next problem became obvious: what do you do with them?

Dumping everything into a single Slack channel is useless after the first day. Your team mutes it. The alert becomes wallpaper. So we built routing rules. A bug report goes to your Linear board or Jira. A crisis alert goes to a dedicated channel or Slack thread where your team actually looks. Feature requests route to wherever your product conversation lives. We let you choose: Linear, GitHub Issues, Trackr, Shpd, or just keep it in Slack.

The crisis alert itself is deliberately minimal. It doesn't tell you how to fix it. It tells you something has changed, where it's being discussed, and how much momentum it has. You still have to think. But you're thinking while the window is open, not after it has closed.

What we learned about speed and usefulness

Speed without direction is just noise. We could have built alerts that fire every three minutes. Instead, we chose a rhythm that matches how real teams work. That's a harder problem than it sounds. It requires asking your customers not how fast they want alerts, but what they can actually do with them. It requires resisting the instinct to make every feature as aggressive as possible.

The fifteen minute window is also honest. We're not pretending we can catch every crisis at the exact moment it starts. We're saying: by the time you read this, the pattern is clear enough to act on. That's the contract.