Weekly digest or realtime alerts: what changes decisions?

From the SoleOS answers series — written about our own product space; grounded in published definitions and documented behavior, never invented numbers.

Realtime alerts are for things that are actively breaking — a webhook silently failing, a payment processor erroring, a crash rate spiking after a release. Weekly digests are for things that require judgment — which app to prioritize, whether a growth trend is real, whether it's time to kill something. If you only have time to build one cadence into your workflow, build the weekly one first, because most of the decisions that actually move a solo portfolio forward don't happen in the moment you see a number — they happen when you sit down with a cold coffee and compare this week to the last four.

That's a strong claim, so let's unpack why, and where realtime still earns its keep.

The decision test: would you act on it today?

A useful filter for any metric is: if this number changed right now, would I do something about it in the next hour? For most portfolio metrics, the honest answer is no. MRR moving by a few percent, a slight dip in Search Console impressions, a new free-trial signup, an App Store review coming in at 4 stars instead of 5 — none of these require you to drop what you're doing. They require you to notice a pattern over days or weeks and then make a call.

Realtime passes the test for a much narrower set of events:

• A payment webhook stops firing (Stripe or RevenueCat) — you could be losing revenue data or, worse, actual revenue, right now.
• A crash-free rate drops sharply after a release — users are having a bad experience this minute.
• A server or API integration goes down — something is broken, not just trending.
• A spike in failed payments on a specific app — see how failed payments quietly erode your MRR for why this one deserves fast attention even though it's "just a number."

Everything else is a digest problem, and treating it as an alert problem is how founders end up with alert fatigue — muting notifications until the one that actually mattered gets muted too.

Why weekly beats daily for strategic calls

Daily sits in an awkward middle ground: too frequent to show real trend, too infrequent to catch emergencies. Day-to-day noise in installs, trial starts, or pageviews is often just noise — traffic source mix, timezone effects, a single refund skewing a tiny app's numbers. Looking at it daily trains you to react to randomness.

Weekly is usually the shortest window where a real trend separates from noise for an indie-scale product. SoleOS actually requires a minimum of 21 days of data before it will show a revenue projection, specifically because shorter windows are too noisy to extrapolate from responsibly — the same logic applies to your own weekly review. You're not trying to catch the dip; you're trying to confirm the dip is real before you spend a Saturday building a fix for it.

A weekly digest is also the natural unit for the decisions that matter across a portfolio of five, ten, or twenty products: which app gets your limited hours this week, whether a pricing change from two weeks ago actually moved conversion, whether an app has quietly crossed into "costs more time than it returns" territory. These aren't single-metric decisions — they're comparisons across apps, which is exactly what a once-a-week sit-down with the metrics dictionary open is good for and what a phone notification is bad for.

What a good split actually looks like

A workable setup for someone running multiple apps on their own:

Realtime (push or email, same day):

• Payment processor errors or disconnections
• Failed-payment spikes above your normal baseline
• Crash rate or error rate crossing a threshold post-release
• A connector going stale (OAuth token expired, webhook silent)

Weekly digest (one sitting, same day each week):

• MRR and active subscriber movement per app
• Trial-to-paid conversion trend
• Organic traffic and impression trends (Search Console, Bing)
• App store ranking and review trend
• Which app grew, which stalled, which needs a decision this month

Monthly or quarterly (longer horizon):

• Revisiting kill criteria — see real numbers from a 10-app portfolio for what that actually looks like in practice
• Pricing and positioning reviews
• Reallocating hours across the portfolio

The mistake to avoid is collapsing all three into "check it when I think of it," which is the default for most solo founders and the reason small warning signs get missed for months.

Where realtime alerts earn their cost

Alerts aren't free — every one you set up is something that can wake you up or interrupt deep work, so they should be reserved for things where delay has a real cost. Stripe and RevenueCat disconnecting is a good example: if you're tracking Stripe and RevenueCat together, a silent disconnection means your dashboard looks fine while actually showing stale numbers, which is worse than no dashboard at all. That's worth an alert. A 2% week-over-week dip in one app's DAU is not.

A decent rule: alert on absence and errors (data stopped flowing, a request failed), review on trend (a number moved in a direction over time). The first category is binary and time-sensitive. The second needs context you can only get by looking at more than one data point.

Where you don't need either

If you're running one app, or your portfolio is genuinely small enough to hold in your head, a dedicated digest-and-alert system is probably overkill — a glance at Stripe's dashboard and your app store console once a week will tell you what you need to know. The split described here starts paying off once you're juggling enough products that "just checking each dashboard" takes real time, or you've been burned by missing a trend because it was buried across four separate tools.

SoleOS leans toward the digest side of this split deliberately: a weekly rollup across connected apps (RevenueCat, Stripe, PostHog, GA4, Search Console, Bing, App Store Connect, Google Play, Firebase, Supabase) plus threshold-based alerts for the handful of things that genuinely need same-day attention, rather than a firehose of notifications for every metric tick. This post is published by SoleOS about its own category, so take the framing with that in mind — a spreadsheet and a calendar reminder can do the same job if you're disciplined about the cadence, and the free spreadsheet comparison is worth a look before you pay for anything.

Frequently asked questions

Isn't realtime always better, since you find out sooner?

Finding out sooner only helps if you can act sooner, and for most strategic metrics — growth rate, conversion trend, which app deserves attention — acting on a single data point usually means acting on noise. Realtime is better specifically for operational failures (payments, crashes, data pipeline breaks) where every hour of delay compounds the damage.

How do I decide my own alert thresholds?

Start by looking at your normal week-to-week variance per metric, per app — a tool that keeps metric history per project, or your own spreadsheet of weekly snapshots, works for this. Set alert thresholds meaningfully outside that normal range, not at the first sign of movement, or you'll end up ignoring them within a month.

Should every app in my portfolio get the same alert rules?

No — a five-year-old app with steady revenue needs different thresholds than a two-month-old launch where volatility is expected. Apply alerts per app based on its own baseline, not a single portfolio-wide rule.

What if I don't have time for a weekly review at all?

Then biweekly is a reasonable fallback, but don't go longer than a month — trends that would have been a quick fix at two weeks become a bigger problem at six, especially for things like a dip in app store conversion or a slow leak in failed payments.

Does SoleOS send realtime alerts or just a digest?

SoleOS is built around the weekly-review habit plus threshold alerts for the operational issues described above, not a stream of real-time pings for every metric change. If you want granular, instant notifications for every event, a dedicated monitoring tool alongside your portfolio dashboard will serve you better than asking one tool to do both jobs well.