The 10 Metrics Every SaaS Founder Should Be Alerted on in Real Time

Most founders check dashboards. Once a day, maybe. When they remember.

The problem with dashboards is timing. By the time you open Stripe and notice MRR dropped, the problem has been running for hours. By the time you check your analytics and see signups stopped, you've already lost a day of leads. By the time a customer emails about a broken checkout, hundreds of people already abandoned it.

Dashboards tell you what happened. Alerts tell you what's happening — right now, while you can still do something about it.

This post covers the 10 metrics every SaaS founder should be alerted on, what to watch for, and exactly when an alert should fire.

The Alerting Philosophy First

Before the list — a principle that makes all of this work:

Alert on anomalies, not absolutes.

A fixed threshold ("alert if signups drop below 10/day") sounds sensible until you realise 10 signups is normal on a Sunday and catastrophic on a Monday after a Product Hunt launch. The threshold that stops false positives creates missed detections, and vice versa.

The right approach: alert when a metric is abnormal for that metric, at that time, given your current patterns. This is what ML anomaly detection does — it learns your baseline including time-of-day and day-of-week variation, and alerts on genuine statistical deviations rather than fixed lines.

For metrics where you need a hard floor ("never let churn exceed X"), use both: a fixed threshold as a hard backstop and anomaly detection as the early warning system.

With that in mind — here are the 10.

1. New Signups — Your Growth Pulse

What it measures: how many new users are starting trials or creating accounts, per hour or per day.

Why it matters: new signups are the leading indicator of everything downstream — activation, conversion, MRR growth. A signup slowdown that goes undetected for 24 hours is a full day of pipeline you can't recover.

What to alert on:

• Signup rate drops significantly below your baseline for that time of day (anomaly detection)
• No signups at all for a window that's abnormally long — could mean your signup form is broken, your landing page is down, or a campaign link is dead
• Signup spike significantly above baseline — could mean a campaign is working, or a bot is creating fake accounts

The silent failure to watch for: your signup form is broken for mobile users. Desktop signups are still coming in, masking a 60% drop in overall conversion. Without per-source signup monitoring, you won't see this for days.

Alert setup:

import notilens

nl = notilens.init(name="saas-signups")

def on_user_registered(user):
    run = nl.task("signup")
    run.start()
    run.track("user.registered", f"New signup: {user['email']}",
               meta={"plan": user.get("plan", "trial"), "source": user.get("utm_source")})
    run.complete("Signup processed")
    # Smart Silence Detection alerts if signups go abnormally quiet

2. Trial-to-Paid Conversion — Your Activation Signal

What it measures: how many trial users convert to a paid plan, within your trial window.

Why it matters: if your conversion rate drops, you're losing revenue invisibly. The trial users are there — they just aren't converting. Something changed in your onboarding, your pricing page, or your product.

What to alert on:

• Trial-to-paid conversion rate drops below your rolling baseline
• A trial expires without converting (not an alert per user — aggregate trend)
• Conversion spike — a campaign or feature change is working

The silent failure to watch for: your upgrade flow has a broken payment step for a specific card type. Users are hitting the pricing page, clicking upgrade, hitting an error, and leaving. You see trial ends. You don't see the attempted upgrades that failed.

Alert setup: track subscription.created events relative to trial expiry events. Alert when the ratio drops significantly below your baseline conversion rate.

3. MRR Movement — Your Revenue Heartbeat

What it measures: changes to Monthly Recurring Revenue — new MRR from conversions, expansion MRR from upgrades, churned MRR from cancellations.

Why it matters: MRR is the number. Everything else feeds into it. Knowing in real time when MRR moves — and why — is the difference between a founder who's ahead of their business and one who's always catching up.

What to alert on:

• New MRR event (new subscription created) — a win worth knowing immediately
• MRR expansion (upgrade) — a signal your product is working
• Churned MRR event (subscription cancelled) — a loss worth investigating immediately
• MRR contraction (downgrade) — a leading indicator of churn risk
• Daily MRR total drops more than X% from previous day (hard threshold)

The signal most founders miss: a sudden cluster of downgrades — 3 customers dropping from a higher tier on the same day. Individually each is noise. Together they signal something changed: a competitor moved, a feature expectation wasn't met, a price point is wrong.

Alert setup:

def on_subscription_event(event):
    run = nl.task("mrr-movement")
    run.start()

    event_type = event["type"]  # created, updated, deleted
    amount     = event["plan"]["amount"] / 100

    run.metric("mrr_change", amount if event_type == "created" else -amount)
    run.track(f"subscription.{event_type}",
              f"MRR {'+'  if event_type == 'created' else '-'}${amount:.2f}/mo",
              meta={"customer": event["customer"], "plan": event["plan"]["nickname"]})
    run.complete(f"MRR event processed")

4. Churn Events — Your Retention Warning System

What it measures: subscription cancellations and the reasons behind them.

Why it matters: churn is expensive — acquiring a customer costs 5–7x what retaining one costs. Knowing immediately when a customer cancels lets you act: a win-back email while they're still warm, a support call to understand why, a product change if a pattern emerges.

What to alert on:

• Any cancellation above a certain plan value (e.g. alert on every Team or Enterprise cancel)
• Churn rate spikes significantly above your daily baseline
• Cluster of cancellations in a short window — suggests a systemic problem
• Cancellation reason clusters — multiple cancellations citing "missing feature" or "too expensive"

The insight most founders miss: churn isn't random. It clusters. Three cancellations in one day from customers who all signed up in the same cohort, on the same plan, after the same campaign — that's a signal. Real-time churn monitoring lets you see the pattern as it forms, not 30 days later in a cohort analysis.

Alert setup: alert immediately on any cancellation > $50 MRR impact. Alert on anomalous churn rate compared to your rolling 7-day baseline.

5. Payment Failures — Your Revenue Protection Layer

What it measures: failed payment attempts — both new subscriptions and recurring billing failures.

Why it matters: failed payments mean lost revenue. Some are recoverable (expired card, temporary decline) — but only if you act on them quickly. A billing failure that sits unaddressed for a week is a churned customer who thinks they cancelled.

What to alert on:

• Any payment failure on a high-value subscription (e.g. > $100/month)
• Payment failure rate spikes above your baseline (card network issue, gateway problem)
• Recurring billing failure for the same customer 2+ times (dunning risk)
• All payment failures from a specific payment method (gateway configuration issue)

The silent failure to watch for: your payment gateway has a regional outage. Customers from a specific country are getting declined. The failure rate looks normal globally. You only see it when you alert per payment method or per region — not on the aggregate.

Alert setup: use Stripe's payment_intent.payment_failed and invoice.payment_failed events. Alert immediately on any recurring billing failure — these are your existing paying customers.

6. Activation Rate — Your Onboarding Health Check

What it measures: what percentage of new signups reach your key activation milestone within a defined window (e.g. completing onboarding, connecting an integration, sending a first message).

Why it matters: activation is the single best predictor of conversion and retention. A user who activates is 3–5x more likely to convert and 2x more likely to stay. A drop in activation rate means your onboarding broke — a flow step is failing, an email isn't sending, a key feature isn't loading.

What to alert on:

• Activation rate drops significantly below your baseline
• New user reaches day 3 of trial without completing activation milestone (individual trigger for intervention)
• Activation step failure — a specific onboarding step is erroring or not completing

The silent failure to watch for: your onboarding email sequence broke. New users sign up, get no emails, and never come back because they don't know what to do next. Your signup numbers look fine. Your activation rate is silently collapsing.

Alert setup: track user.activated events (however you define activation in your product). Alert when the ratio of activations to signups drops significantly within a rolling 24-hour window.

7. Feature Usage Drops — Your Product Health Signal

What it measures: usage of key features per active user per day, compared to baseline.

Why it matters: a sudden drop in feature usage almost always means something broke — a bug, a UI change that confused users, a performance regression that made the feature too slow to use. Users don't file bug reports. They just stop using it.

What to alert on:

• Usage of a core feature drops more than 30% compared to rolling baseline
• A feature that's always used daily has zero usage events today
• API endpoint that powers a core feature has no traffic for an abnormally long window

The signal most founders miss: a feature usage drop often precedes churn by 2–4 weeks. Users disengage from a feature, stop logging in, then cancel. Catching the usage drop early gives you a churn prevention window.

Alert setup: track feature-specific events (report.generated, integration.synced, export.completed) and use Smart Silence Detection on each. Alert when a feature that normally generates dozens of events per day goes quiet.

8. Support Ticket Volume — Your User Experience Proxy

What it measures: incoming support ticket volume, per hour or per day.

Why it matters: support tickets are a lagging indicator of product problems. By the time tickets start coming in, the problem has been running long enough to frustrate users into writing about it. But a spike in tickets is still a faster signal than waiting for churn.

What to alert on:

• Support ticket volume spikes 2x above your daily baseline
• Cluster of tickets with similar subject lines (same product area, same error message)
• Zero support tickets for an unusually long period (could mean your ticketing system is broken, not that everything is fine)

The nuance: a spike in support tickets during a marketing push is expected and healthy — new users with onboarding questions. A spike in support tickets from existing users on a quiet Tuesday is a product problem. Anomaly detection that accounts for context catches the distinction.

Alert setup: integrate your helpdesk (Intercom, Zendesk, Linear) with NotiLens via webhook. Alert when ticket creation rate exceeds your learned baseline for that time period.

9. API Error Rate — Your Integration Health Signal

What it measures: the percentage of API requests returning 4xx or 5xx responses, per endpoint.

Why it matters: SaaS products live and die on their integrations. If your API is erroring, your customers' workflows are breaking — automation tools are failing, integrations are throwing errors, data isn't syncing. These are the problems that trigger immediate cancellation.

What to alert on:

• 5xx error rate exceeds 1% over any 5-minute window (server errors — your problem)
• A specific endpoint's error rate exceeds 5% (targeted failure, not global)
• 4xx rate spikes — could indicate an API breaking change that's affecting existing integrations
• API endpoint receives no traffic for an abnormally long window (silence alert)

The distinction that matters: a global API error rate of 0.5% looks healthy. But if /api/webhooks/stripe is returning 500s for 30% of requests while every other endpoint is fine, you have a critical problem hidden in the aggregate. Monitor per endpoint, not just globally.

Alert setup: add NotiLens middleware to your API server (see our API monitoring guide). run.error() on every 5xx, run.metric("error_rate", ...) tracked per endpoint.

10. Billing Renewal Upcoming + Failed — Your MRR Continuity Signal

What it measures: upcoming subscription renewals and whether they succeed or fail.

Why it matters: renewal failures are often invisible until a customer notices they've lost access. By then, they've already had a bad experience. Catching a renewal failure the moment it happens — before the customer notices — lets you reach out proactively, fix the payment method, and save the relationship.

What to alert on:

• Renewal payment failed → immediate alert, especially for high-value customers
• Customer's card on file is expiring within 14 days → prompt outreach before the failure happens
• Renewal succeeded for a high-value customer — worth knowing, good signal
• Renewal failure rate spikes above baseline → could indicate a payment method issue across a customer cohort

The proactive play: set up alerts 14 days before renewal for customers with expiring cards. A "hey, your card is expiring soon" email sent proactively converts better than a "your payment failed" email sent after the fact. The first feels like service. The second feels like a problem.

Alert setup: use Stripe's customer.subscription.trial_will_end and invoice.upcoming events in combination with card expiry metadata. Alert immediately on invoice.payment_failed for any subscription > $50/mo.

Putting It All Together

Here's the full alert setup for a SaaS founder in one NotiLens topic structure:

Ten topics. All covered. Smart Silence Detection and ML anomaly detection active on each. On-call routing to your phone for critical events (payment failures, churn, API errors), Slack for informational ones (new signups, MRR wins).

For the week-by-week order to set all of this up without being overwhelmed, see The Founder's Monitoring Stack.

The Founder Who Knows vs The Founder Who Finds Out

There are two types of SaaS founders when something breaks:

The founder who finds out: a customer tweets. A support ticket comes in. They open their analytics and see a metric that looks wrong. They investigate. The problem has been running for 12 hours.

The founder who knows: an alert fires at 3:17am. They see it at 7am. The problem has been running for 4 hours, not 12. They fix it before the business day starts. The first customer to experience the issue gets a proactive email explaining what happened and what was done.

The difference isn't intelligence or hard work. It's monitoring setup.

The 10 metrics above are the ones that matter most for SaaS — the ones where a 6-hour delay in detection turns a fixable problem into an expensive one.

Set up the alerts once. Let NotiLens watch while you sleep.

Try NotiLens free for 7 days — no credit card required.

Start Free Trial →

Frequently Asked Questions

Do I need to monitor all 10 from day one? No. Start with the three that matter most at your current stage. Pre-revenue: signups and activation rate. Post-revenue: payment failures and churn events. Growing: MRR movement and API error rate. Add the others as your product matures and you have enough data for anomaly detection to learn your patterns.

How do I avoid alert fatigue across 10 metric streams? Route alerts by severity. Critical events (payment failures, churn above a threshold, API error spikes) → push notification to your phone. Informational events (new signup, MRR win, feature usage trends) → Slack or email digest. The goal is to never miss a critical alert — not to be notified about everything.

What if I'm pre-product and don't have all these metrics yet? Start with what you have. Even at the earliest stage, you can monitor signups, payment events (if you're charging), and API health. Each metric you add as you build is one more early warning system. The monitoring infrastructure scales with your product.

How is this different from having Stripe, Mixpanel, and Intercom dashboards open? Dashboards require you to look. Alerts come to you. The best founders aren't the ones who check dashboards most frequently — they're the ones who've set up the right alerts so they don't need to. This setup replaces the mental overhead of "I should check the dashboard" with the certainty that if something is wrong, you'll know.

Should I alert on positive events too (new signups, MRR wins)? Yes, selectively. A new Enterprise signup, a $500 MRR month, a feature milestone — these are worth knowing in real time for motivation and decision-making. Keep positive alerts limited to meaningful milestones so they don't become noise. The ratio should be roughly 80% problem alerts, 20% win alerts.