Представьте: ваше мобильное приложение после очередного релиза начинает терять пользователей, но вы узнаёте об этом через 4 часа, когда тикеты в поддержку уже исчисляются сотнями. Проблема не в отсутствии данных — метрики стабильности собираются, но алерты либо не настроены, либо генерируют лавину ложных срабатываний. Именно для таких ситуаций мы выполняем настройку алертов по метрикам стабильности мобильного приложения: Crash-Free Users Rate, ANR Rate, Watchdog Termination и других. Каждый настроенный сигнал означает реальную деградацию и требует действия. За нашу практику мы провели аудит и настройку мониторинга для 30+ мобильных приложений под iOS и Android — от стартапов до финтеха с 2 млн пользователей.
Какие метрики стабильности требуют алертов и каковы их пороги?
Crash-Free Users Rate — процент пользователей без крэшей за период. Google Play Console определяет плохое приложение как с более 1.09% crashes per session. Apple рекомендует более 99% Crash-Free Users. Важно считать по уникальным пользователям, а не по сессиям.
ANR Rate (Android) — количество ANR на 1000 пользователей в день. Порог плохого: более 0.47% ANR Rate, как указано в Google Play Console guidelines.
Watchdog Termination Rate (iOS) — доля сессий с Watchdog Termination. Хороший ориентир — менее 0.1%.
App Hang Rate (iOS) — сессии с зависанием UI более 250 ms. Для быстрой ориентации используйте таблицу порогов:
| Метрика | Платформа | WARNING | CRITICAL |
|---|---|---|---|
| Crash-Free Users | iOS | < 99% | < 98% |
| Crash-Free Users | Android | < 99% | < 98% |
| ANR Rate | Android | > 0.3% | > 0.47% |
| Watchdog Termination | iOS | > 0.05% | > 0.1% |
| App Hang Rate | iOS | > 0.5% | > 1% |
Эти значения — стартовая точка. Под каждый проект мы подбираем пороги индивидуально, анализируя исторические данные.
Почему нормировка по сессиям обязательна?
Алерт на абсолютное число крэшей без нормировки — классическая ошибка. При росте аудитории число крэшей растёт, даже если Crash-Free Rate стабилен. Алерт постоянно срабатывает, команда перестаёт реагировать. Нормировка по сессиям или пользователям решает эту проблему: мы считаем не количество крэшей, а процент затронутых сессий. Это даёт стабильный порог вне зависимости от объёма трафика.
Как velocity alert снижает шум оповещений?
Velocity alert срабатывает при резком изменении метрики (например, рост процента крэшей на 0.5% за час), а не при превышении абсолютного порога. Это снижает шум алертов и количество ложных срабатываний. В сочетании с нормировкой по сессиям вы получаете надёжную систему, которая сигнализирует только о реальных проблемах.
Реальный кейс: настройка алертов для финтех-приложения
Из нашей практики: финтех-приложение с аудиторией 2 млн пользователей. Crash-Free Rate держался на уровне 98%, но команда не замечала деградацию на отдельных устройствах. После аудита мы выяснили, что алерт был настроен на абсолютное число крэшей — 500 в день. Когда аудитория выросла на 30%, алерт срабатывал каждые 2 часа, и его отключили.
Мы переконфигурировали систему: установили velocity alert на рост доли крэшей более чем на 0.5% за час, добавили нормировку по сессиям и настроили два уровня severity. Через неделю команда получила ровно 3 алерта, каждый из которых требовал действия: один — реальный баг в новой версии, два — ложные срабатывания из-за тестового трафика. Мы отфильтровали тестовые девайсы по User-Agent, и ложные сигналы исчезли.
Результат: время реакции на инциденты сократилось с 4 часов до 30 минут, а стабильность приложения выросла до 99.5% Crash-Free Users. Настройка velocity alerts позволила снизить шум алертов и повысить доверие к системе оповещений. Если вы хотите такую же систему — свяжитесь с нами для аудита.
Как настроить алерты в популярных сервисах: пошаговое руководство
Firebase Crashlytics
// Firebase Alert Webhook (настраивается в консоли Firebase) // При velocity alert — POST на ваш endpoint // Пример payload от 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 срабатывает при резком росте процента затронутых сессий. Настройка порога — в Firebase Console.
Sentry с CRON-проверкой
# Sentry API — создание Monitor через 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"] } } ) Но удобнее через UI: Issues → Alerts → New Alert Rule. Условие: Number of users affected > 50 за 1 час. Действие: Notify Slack #mobile-incidents.
Datadog на основе RUM-метрик
# Datadog Monitor query (Metric Alert) rum(mobile,*).crash_count{env:production,service:ios-app}.rollup(sum, 3600) # Условие: > 100 крэшей в час → CRITICAL # > 50 крэшей в час → WARNING Для Crash-Free Rate:
# Вычисляемая метрика в Datadog (1 - (sum:rum.crash_count{service:ios-app} / sum:rum.session_count{service:ios-app})) * 100 # Алерт: если < 99% → WARNING, < 98% → CRITICAL Маршрутизация алертов
# PagerDuty + Alertmanager (для Prometheus-based мониторинга) 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' Что входит в работу по настройке алертов
- Анализ текущих метрик стабильности и выявление проблемных зон.
- Настройка velocity alerts в Crashlytics, Sentry, Datadog под ваш стек.
- Конфигурация каналов оповещения (Slack, PagerDuty, Telegram) с разграничением по критичности.
- Написание runbook для каждого типа алерта: что делать при срабатывании.
- Обучение команды работе с системой мониторинга.
- Поддержка в течение 2 недель после запуска — корректировка порогов и устранение инцидентов.
Ориентировочные сроки
Базовая настройка алертов в одном сервисе — от 4 часов. Полная интеграция с маршрутизацией и документацией — 1–2 дня. Стоимость рассчитывается индивидуально в зависимости от стека и объёма работ.
Типичные ошибки при настройке алертов
- Единый порог для всех версий. Новая версия с малой аудиторией может иметь высокий крэш-рейт статистически незначимо. Добавляйте условие
sessions > 1000перед проверкой. - Нет алерта на улучшение. Если Crash-Free Rate резко вырос — это может означать успешный hotfix. Двунаправленные алерты помогают оценивать эффект релизов.
- Игнорирование фоновых метрик (ANR, Watchdog). Пользователь может не видеть крэша, но качество работы страдает.
Для выбора инструмента используйте таблицу сравнения:
| Сервис | Тип алерта | Интеграции | Особенности |
|---|---|---|---|
| Firebase Crashlytics | Velocity alert, issue alerts | Slack, PagerDuty, email | Встроен в экосистему Firebase |
| Sentry | Metric alerts, monitor, cron | Slack, PagerDuty, GitHub | Гибкие правила для кросс-платформы |
| Datadog RUM | Metric monitor, anomaly detection | Slack, PagerDuty, Webhook | Вычисляемые метрики, интеграция с RUM |
Свяжитесь с нами, чтобы заказать аудит стабильности вашего приложения. Мы гарантируем прозрачную настройку алертов, которые не будут шуметь. Наши инженеры — сертифицированные разработчики Apple и Google с многолетним опытом. Получите консультацию — оценим ваш проект и предложим оптимальное решение.