Configuring Alerts for Mobile App Stability Metrics

Imagine: your mobile app after another release starts losing users, but you find out about it 4 hours later, when support tickets are already in the hundreds. The problem is not lack of data – stability metrics are collected, but alerts are either not configured or generate an avalanche of false positives. It is for such situations that we configure alerts based on mobile app stability metrics: Crash-Free Users Rate, ANR Rate, Watchdog Termination, and others. Each configured signal indicates real degradation and requires action. In our practice, we have audited and configured monitoring for 30+ mobile apps on iOS and Android – from startups to fintech with 2 million users.

Which stability metrics require alerts and what are their thresholds?

Crash-Free Users Rate – the percentage of users without crashes over a period. Google Play Console defines a poor app as having more than 1.09% crashes per session. Apple recommends over 99% Crash-Free Users. It is important to count by unique users, not sessions.

ANR Rate (Android) – number of ANRs per 1000 users per day. Poor threshold: more than 0.47% ANR Rate, as per Google Play Console guidelines.

Watchdog Termination Rate (iOS) – share of sessions with Watchdog Termination. A good benchmark is less than 0.1%.

App Hang Rate (iOS) – sessions with UI hanging for more than 250 ms. For quick reference, use the threshold table:

These values are a starting point. For each project, we select thresholds individually by analyzing historical data.

Why is normalizing by sessions mandatory?

An alert on an absolute number of crashes without normalization is a classic mistake. As the audience grows, the number of crashes increases even if the Crash-Free Rate remains stable. The alert fires constantly, and the team stops responding. Normalizing by sessions or users solves this problem: we count not the number of crashes, but the percentage of sessions affected. This provides a stable threshold regardless of traffic volume.

How does a velocity alert reduce notification noise?

A velocity alert triggers on a sharp change in the metric (e.g., a 0.5% increase in crash percentage per hour), not on exceeding an absolute threshold. This reduces alert noise and false positives. Combined with session normalization, you get a reliable system that signals only real problems.

Real-world case: configuring alerts for a fintech app

From our practice: a fintech app with 2 million users. The Crash-Free Rate held at 98%, but the team did not notice degradation on specific devices. After an audit, we found that the alert was set on an absolute crash count – 500 per day. When the audience grew by 30%, the alert fired every 2 hours, and they turned it off.

We reconfigured the system: set a velocity alert on a crash percentage increase of more than 0.5% per hour, added session normalization, and configured two severity levels. After a week, the team received exactly 3 alerts, each requiring action: one real bug in the new version, two false positives from test traffic. We filtered test devices by User-Agent, and the false signals disappeared.

Result: incident response time dropped from 4 hours to 30 minutes, and app stability increased to 99.5% Crash-Free Users. Configuring velocity alerts reduced alert noise and increased trust in the notification system. If you want such a system, contact us for an audit.

How to configure alerts in popular services: step-by-step guide

Firebase Crashlytics

// Firebase Alert Webhook (configured in Firebase Console) // On velocity alert – POST to your endpoint // Example payload from Firebase: { "type": "crashlytics.velocityAlert", "data": { "issue": { "id": "issue_id", "title": "Fatal Exception: java.lang.NullPointerException", "crashPercentage": 2.3, "firstVersion": "2.1.0", "latestVersion": "2.3.1" } } } 

Velocity Alert triggers on a sharp increase in the percentage of sessions affected. Threshold configuration is done in the Firebase Console.

Sentry with CRON check

# Sentry API – creating a Monitor via REST import requests response = requests.post( "https://sentry.io/api/0/organizations/YOUR_ORG/monitors/", headers={"Authorization": "Bearer YOUR_TOKEN"}, json={ "name": "Crash-Free Rate Drop", "type": "cron_job", "config": { "schedule_type": "interval", "schedule": [1, "hour"] } } ) 

But it is easier via UI: Issues → Alerts → New Alert Rule. Condition: Number of users affected > 50 in 1 hour. Action: Notify Slack #mobile-incidents.

Datadog based on RUM metrics

# Datadog Monitor query (Metric Alert) rum(mobile,*).crash_count{env:production,service:ios-app}.rollup(sum, 3600) # Condition: > 100 crashes per hour → CRITICAL # > 50 crashes per hour → WARNING 

For Crash-Free Rate:

# Calculated metric in Datadog (1 - (sum:rum.crash_count{service:ios-app} / sum:rum.session_count{service:ios-app})) * 100 # Alert: if < 99% → WARNING, < 98% → CRITICAL 

Alert routing

# PagerDuty + Alertmanager (for Prometheus-based monitoring) route: group_by: ['service', 'platform'] group_wait: 30s group_interval: 5m repeat_interval: 4h routes: - match: severity: critical service: mobile receiver: pagerduty-mobile-oncall - match: severity: warning service: mobile receiver: slack-mobile-channel receivers: - name: pagerduty-mobile-oncall pagerduty_configs: - service_key: YOUR_PD_SERVICE_KEY - name: slack-mobile-channel slack_configs: - api_url: YOUR_SLACK_WEBHOOK channel: '#mobile-stability' 

What is included in the alert setup work

• Analysis of current stability metrics and identification of problem areas.
• Configuration of velocity alerts in Crashlytics, Sentry, Datadog for your stack.
• Setup of notification channels (Slack, PagerDuty, Telegram) with severity differentiation.
• Writing a runbook for each alert type: what to do when it fires.
• Training the team on the monitoring system.
• Support for 2 weeks after launch – adjusting thresholds and handling incidents.

Estimated timelines

Basic alert setup in one service – from 4 hours. Full integration with routing and documentation – 1–2 days. Cost is calculated individually based on the stack and scope of work.

Typical mistakes when configuring alerts

• Single threshold for all versions. A new version with a small audience may have a high crash rate that is statistically insignificant. Add a condition sessions > 1000 before checking.
• No alert on improvement. If Crash-Free Rate sharply increases, it might mean a successful hotfix. Bidirectional alerts help evaluate release impact.
• Ignoring background metrics (ANR, Watchdog). The user may not see a crash, but the quality of work suffers.

For tool selection, use the comparison table:

Contact us to order a stability audit of your application. We guarantee transparent alert configuration that will not create noise. Our engineers are certified Apple and Google developers with many years of experience. Get a consultation – we will assess your project and propose the optimal solution.