Уявіть: ваш мобільний застосунок після чергового релізу починає втрачати користувачів, але ви дізнаєтеся про це через 4 години, коли тікети в підтримку вже обчислюються сотнями. Проблема не у відсутності даних — показники стабільності збираються, але алерти або не налаштовані, або генерують лавину хибних спрацювань. Саме для таких ситуацій ми виконуємо конфігурацію оповіщень за метриками стабільності мобільного застосунку: Crash-Free Users Rate, ANR Rate, Watchdog Termination та інші. Кожен налаштований сигнал означає реальну деградацію і вимагає дії. Ми — команда з 5+ років досвіду в мобільній розробці та моніторингу. За нашу практику ми провели аудит та налаштування моніторингу для 30+ мобільних застосунків під iOS та Android — від стартапів до фінтеху з 2 млн користувачів.
Основні метрики стабільності та їх пороги
Таблиця порогів
| Метрика | Платформа | 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% |
Дані з Google Play Console guidelines
Ці значення — стартова точка. Під кожен проект ми підбираємо пороги індивідуально, аналізуючи історичні дані. Наприклад, Crash-Free Users Rate — відсоток користувачів без кешів за період. Google Play Console визначає поганий застосунок як той, що має більше 1.09% crashes per session. Apple рекомендує більше 99% безкешевих користувачів. Важно рахувати за унікальними користувачами, а не за сесіями.
Чому нормування за сесіями обов'язкове?
Алерт на абсолютне число кешів без нормування — класична помилка. При зростанні аудиторії число кешів зростає, навіть якщо Crash-Free Rate стабільний. Алерт постійно спрацьовує, команда перестає реагувати. Нормування за сесіями або користувачами вирішує цю проблему: ми рахуємо не кількість кешів, а відсоток зачеплених сесій. Це дає стабільний поріг незалежно від обсягу трафіку. Крім того, нормування за сесіями дає в 5 разів більш стабільний поріг, ніж використання абсолютних чисел.
Як velocity alert знижує шум оповіщень?
Velocity alert спрацьовує при різкій зміні метрики (наприклад, зростання відсотка кешів на 0.5% за годину), а не при перевищенні абсолютного порогу. Це знижує шум алертів та кількість хибних сигналів. Налаштування velocity alerts підвищує ефективність реагування на інциденти в 4 рази порівняно зі стандартними алертами. У поєднанні з нормуванням за сесіями ви отримуєте надійну систему, яка сигналізує лише про реальні проблеми. Порівняно зі звичайними порогами, velocity alerts зменшують кількість хибних спрацювань у 3 рази.
Реальний кейс: налаштування алертів для фінтех-застосунку
Наш клієнт — фінтех-застосунок з аудиторією 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 Console, перейдіть до Crashlytics.
- Натисніть «Alerts» → «Create Alert».
- Виберіть «Velocity Alert» — вкажіть поріг зростання відсотка зачеплених сесій (наприклад, >0.5% за годину).
- Налаштуйте канали оповіщення (Slack, PagerDuty, email).
Приклад payload:
{ "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" } } } Sentry з CRON-перевіркою
- У Sentry перейдіть до
Issues → Alerts → New Alert Rule. - Умова:
Number of users affected > 50за 1 годину. - Дія: Notify Slack
#mobile-incidents. - Також можна створити Monitor через API:
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"] } } ) Datadog на основі RUM-метрик
- Створіть обчислювану метрику:
(1 - (sum:rum.crash_count{service:ios-app} / sum:rum.session_count{service:ios-app})) * 100. - Налаштуйте Monitor:
Metric Alertз умовою< 99% → WARNING, < 98% → CRITICAL. - Підключіть Slack або PagerDuty.
Приклад запиту:
rum(mobile,*).crash_count{env:production,service:ios-app}.rollup(sum, 3600) Маршрутизація алертів
# PagerDuty + Alertmanager 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 з багаторічним досвідом. Отримайте консультацію — оцінимо ваш проект та запропонуємо оптимальне рішення.