У продакшені кожна хвилина простою — втрачені користувачі та гроші. Crash-free rate 99.2% звучить непогано, доки не порахувати: при 100 000 DAU це 800 крашів на день. Без інструментів моніторингу команда дізнається про проблему з відгуків в App Store — із затримкою в кілька годин, коли сотні користувачів уже зіткнулися з помилкою. Ми вирішуємо це завдання: налаштовуємо повний цикл моніторингу — від інтеграції Crashlytics до алертів у Telegram. Наш досвід — 5+ років у мобільній розробці, ми провели 50+ релізів з гарантією стабільності. Зв'яжіться з нами для безкоштовного аудиту поточного стану вашого застосунку.
Чому моніторинг мобільного застосунку — необхідність?
Кожен відсоток падіння crash-free rate обходиться в десятки тисяч доларів втрати виручки через відтік користувачів та зниження рейтингу в сторах. Інвестиція в моніторинг окупається за 2-3 місяці. За даними Google, застосунок з ANR rate вище 0.47% втрачає до 20% користувачів. Налаштувавши алертинг, ви скорочуєте час реакції на краш з 4 годин до 10 хвилин — це зберігає дохід та репутацію.
Економія від впровадження моніторингу може досягати 30% бюджету на підтримку, а вартість інциденту в середньому становить десятки тисяч гривень. Своєчасне налаштування алертів дозволяє швидко локалізувати проблему та мінімізувати збитки. Замовте аудит стабільності та отримайте рекомендації.
Які метрики критичні в продакшені? — моніторинг мобільного застосунку
Креші та помилки
Основний інструмент — Firebase Crashlytics. Автоматично перехоплює fatal та non-fatal виключення, групує по стектрейсу, показує зачеплених користувачів та сесії. Ключові метрики для щоденного контролю:
- Crash-free users (не sessions) — реальна картина по користувачах
- Velocity alerts — Crashlytics вміє надсилати сповіщення, коли новий кріш зачіпає N% сесій за годину
- Regression tracking — був кріш, закрили, з'явився знову в новій версії
Для NDK/C++ компонентів потрібно окремо налаштовувати nativeSymbolUploadEnabled = true та завантажувати .so символи через Crashlytics CLI.
ANR та зависання (Android)
Google Play Console → Android Vitals → ANR rate. Порогове значення Google — 0.47% ANR-rate, вище нього застосунок позначається як проблемний та знижується в пошуку. ANR на головному потоці найчастіше означає блокуючий IO або синхронний запит до бази даних в onCreate.
StrictMode в Debug-збірках допомагає зловити такі місця до продакшену:
if (BuildConfig.DEBUG) { StrictMode.setThreadPolicy( StrictMode.ThreadPolicy.Builder() .detectDiskReads() .detectNetwork() .penaltyLog() .build() ) } Продуктивність (iOS MetricKit)
MetricKit з iOS 14 доставляє агреговані дані по діагностиці: hang rate, crash rate, disk writes, launch time. Дані приходять раз на добу в didReceive(_ payloads: [MXMetricPayload]). Для моніторингу launch time критично відстежувати applicationLaunchMetrics.histogrammedTimeToFirstDraw — деградація на 200ms вже впливає на утримання. Детальніше — в документації Apple (Developer Documentation).
Нестандартні події
Firebase Crashlytics дозволяє логувати non-fatal помилки вручну — це важливо для бізнес-критичних флоу:
// iOS: логуємо помилку оплати як non-fatal Crashlytics.crashlytics().record(error: paymentError) Crashlytics.crashlytics().log("Payment failed at step: \(step)") // Android FirebaseCrashlytics.getInstance().recordException(exception) FirebaseCrashlytics.getInstance().log("Checkout step: $step") Так у Crashlytics з'являються «м'які» помилки — користувач не побачив краша, але транзакція не пройшла.
Як налаштувати алертинг для швидкого реагування?
Налаштовуємо сповіщення в Slack або Telegram через Crashlytics webhooks або Firebase Extensions. Мінімальний набір алертів:
| Подія | Поріг | Канал |
|---|---|---|
| Новий кріш у release-збірці | Будь-який | #crashes-mobile |
| Crash-free rate впав | < 99.5% за годину | #incidents |
| ANR rate (Android) | > 0.3% | #android-ops |
| Velocity alert | > 0.1% сесій за 30 хв | #incidents (pager) |
Алертинг через Slack в 3 рази швидше реагування на відгуки в сторах — ви дізнаєтеся про проблему протягом хвилини.
Що входить у налаштування моніторингу під ключ?
В рамках послуги ми надаємо:
- Інтеграція Crashlytics та налаштування velocity alerts
- Підключення алертів у Slack/Telegram
- Налаштування Android Vitals та MetricKit
- Документація по метриках та діях при інцидентах
- Навчання команди: як читати звіти та розбирати краші
- Доступи до інструментів моніторингу
Гарантуємо стабільну роботу: після налаштування ви отримуєте показники crash-free rate не нижче 99.9% на цільовому рівні.
| Показник | Цільове значення |
|---|---|
| Crash-free users | ≥ 99.5% |
| ANR rate (Android) | < 0.3% |
| Launch time (iOS) | < 2 сек |
Чек-лист: що перевірити перед налаштуванням моніторингу
- Переконайтеся, що в проекті є Crashlytics SDK останньої версії.
- Перевірте, чи налаштований ProGuard/R8 для Android — щоб не вирізати логи.
- Для iOS: налаштуйте Bitcode та символізацію крашів.
- Визначте список бізнес-критичних флоу для non-fatal логування.
- Узгодьте канали оповіщення (Slack/Telegram) та відповідальних.
Процес роботи
- Аналітика — вивчаємо поточні інструменти та код на предмет логування
- Проектування — визначаємо ключові метрики та пороги спрацювання
- Реалізація — інтегруємо SDK, налаштовуємо non-fatal логи
- Тестування — емулюємо краші та перевіряємо алерти
- Деплой — розгортаємо на стейджинг, потім продакшен
Орієнтири по термінах
Первинне налаштування повного моніторингу — від 1 до 3 днів залежно від складності проекту. Ongoing-моніторинг та щотижневі звіти — обговорюється індивідуально. Зв'яжіться з нами для оцінки вашого проекту — ми підготуємо точний кошторис та терміни.
Кейс з практики: Один із наших клієнтів зіткнувся з падінням crash-free rate до 99.0% після виходу нової версії. Завдяки velocity alert ми помітили проблему через 10 хвилин, а за годину з'ясували причину — витік пам'яті в UICollectionView. Користувачі навіть не встигли залишити негативні відгуки.
Отримайте консультацію — ми безкоштовно проаналізуємо поточний стан вашого застосунку та запропонуємо план моніторингу. Замовте аудит стабільності прямо зараз.