Release Health Monitoring (Sentry) Configuration for Mobile Apps
Our team has 5 years of experience in monitoring configuration for mobile applications and has configured Release Health for over 20 projects. We integrate and configure Sentry Release Health for your app — this provides an objective picture of each release's health before users leave feedback. Without this system, degradation often goes unnoticed until complaints. With Release Health, you get automatic comparison of versions by crash-free rate, adoption, and session count. If metrics fall, Sentry marks the release as Unhealthy and triggers alerts. Our proven track record shows that such a setup pays for itself after the first incident. For example, for an app with 500,000 MAU, we reduced reaction time to regressions from 2 hours to 15 minutes, saving an estimated $2,000 per incident. Automatic monitoring detects issues 3 times faster than analyzing user feedback. We guarantee a thorough setup with comprehensive documentation.
Calculation of Crash Free Rate
Release Health is based on sessions. A session starts when the app launches and ends when it goes to background for more than 30 seconds or is explicitly terminated. Each session is marked as either crashed or ok. Crash Free Rate = (sessions without crashes / total sessions) × 100%. Sentry automatically aggregates this data per release. Sentry Documentation provides official details.
// iOS — Sentry sessions are managed automatically when enableAutoSessionTracking = true
SentrySDK.start { options in
options.dsn = "https://[email protected]/your-project-id"
options.releaseName = "MyApp@\(Bundle.main.releaseVersionNumber)+\(Bundle.main.buildNumber)"
options.environment = "production"
options.enableAutoSessionTracking = true
options.sessionTrackingIntervalMillis = 30_000 // 30 sec in background = new session
}
// Android
SentryAndroid.init(this) { options ->
options.dsn = "https://[email protected]/your-project-id"
options.release = "myapp@${BuildConfig.VERSION_NAME}+${BuildConfig.VERSION_CODE}"
options.environment = "production"
options.enableAutoSessionTracking = true
options.sessionTrackingIntervalMillis = 30_000L
}
The releaseName parameter must match what is used when uploading dSYM (iOS) or ProGuard mapping (Android) to Sentry. Otherwise, Release Health and symbolicated traces will appear under different versions in the UI — a common mistake we fix.
Why Upload dSYM and ProGuard Mapping?
Without symbols, you won't see readable stacktraces in Issues. And without a correct releaseName, Release Health won't link to those issues. We automate the upload via Sentry CLI in CI/CD. Our experienced team ensures a smooth integration.
# Fastlane — Fastfile
lane :upload_dsyms_to_sentry do
sentry_upload_dsym(
auth_token: ENV["SENTRY_AUTH_TOKEN"],
org_slug: "your-org",
project_slug: "ios-app",
dsym_path: "./build/MyApp.app.dSYM"
)
end
Or via sentry-cli in CI/CD:
sentry-cli releases new "[email protected]+456"
sentry-cli releases set-commits "[email protected]+456" --auto
sentry-cli upload-dsyms ./build/MyApp.app.dSYM
sentry-cli releases finalize "[email protected]+456"
set-commits --auto links git commits to the release. This lets you see in Sentry's Issue tracker which commit caused the problem. We ensure this chain is set without breaks.
How to Read Release Health in the Sentry UI?
In the Releases section, the key metric — Crash Free Rate — is displayed. Sentry automatically calculates Adoption (share of users on this version) and session count. A status of Unhealthy is assigned if the Crash Free Rate drops by more than 5% compared to the previous release. We configure this threshold for your project. Typical targets: Crash Free Rate above 99.5%.
| Metric | Description |
|---|---|
| Crash Free Rate | % of sessions without crashes |
| Adoption | % of users on this version |
| Sessions | Total number of sessions |
| Issues | New errors introduced in this version |
How to Set Up Alerts on Degradation?
Use the Sentry API to create alert rules that trigger when a regression is detected. Example in Python:
# Sentry API — create Alert Rule
import requests
rule = {
"name": "Release Health Degradation",
"environment": "production",
"actionMatch": "all",
"conditions": [
{
"id": "sentry.rules.conditions.regression_event.RegressionEventCondition"
}
],
"filters": [
{"id": "sentry.rules.filters.latest_release.LatestReleaseFilter"}
],
"actions": [
{
"id": "sentry.integrations.slack.notify_action.SlackNotifyServiceAction",
"workspace": "SLACK_WORKSPACE_ID",
"channel": "#mobile-releases"
}
],
"frequency": 60
}
requests.post(
f"https://sentry.io/api/0/projects/YOUR_ORG/ios-app/rules/",
headers={"Authorization": "Bearer YOUR_TOKEN"},
json=rule
)
We also create a post-deploy script that compares the new release's Crash Free Rate with the previous one via the API — this allows blocking the pipeline if degradation exceeds the allowed threshold.
Configuration Comparison: iOS vs Android
| Parameter | iOS | Android |
|---|---|---|
| Library | Sentry Cocoa | Sentry Android |
| SDK Version | 8.x | 6.x |
| Auto sessions | enableAutoSessionTracking | enableAutoSessionTracking |
| releaseName format | [email protected]+1 | [email protected]+1 |
| Symbol upload | dSYM | ProGuard mapping |
What's Included in the Work
- Integration of
enableAutoSessionTrackingwith correctreleaseNameformat for iOS and Android - Connecting Sentry CLI in CI/CD for automatic upload of dSYM and ProGuard mapping
- Configuration of git commit tracking via
set-commits - Creation of alerts on Regression Event with notification to Slack or Telegram
- Implementation of post-deploy check of Crash Free Rate as a gate in the pipeline
- Comprehensive documentation of the process and recommendations on metric thresholds
- Access to dashboards and training for your team (up to 1 hour)
- 30 days of post-deployment support (email/chat)
Case Study
In one project — a food delivery app with an audience of 500,000 MAU — after a version update, the crash-free rate dropped by 8% within an hour. Without Release Health, this would have only become known days later through user reviews. Sentry automatically marked the release as Unhealthy and sent an alert to Slack. We rolled back the release within 30 minutes and fixed the regression. Since setting up the system, the number of incidents reaching users has been reduced by 3 times.
Timeline and Cost
Basic Release Health setup takes 4–8 hours (cost: $500–$1,000 depending on app complexity). Full integration with CI/CD and automatic symbol upload takes 1–2 days (cost: $1,500–$3,000). Get a free assessment of your project — contact us. We'll evaluate your project within 30 minutes and propose an integration plan. Our guaranteed methodology ensures a robust setup.







