Guards & Targeting
Guards & Targeting in the OTA Updates area (Configure) — route /ota/guards.
Guards & Targeting lives in the OTA Updates area of the dashboard, under Configure.
At a glance#
| Dashboard route | /ota/guards |
| Area | OTA Updates (ota) |
| Group | Configure |
| Platforms | Available for every app platform. |
| Note | This entry points outside its area's usual /{area}/{slug} pattern. |
What it does#
Guards are automatic rules that stop a bad release without a human watching the dashboard. A guard watches one metric — crash rate, ANR rate, or error rate — over a time window, and if the metric crosses a threshold it takes an action: pause the release, roll it back, or raise an alert. This is the safety net that lets you publish an OTA update and walk away.
Targeting rules live here too: they decide which devices a release reaches, by geography, app-version range, user attribute, segment, audience list, or lifecycle stage.
Configuring a guard#
Each guard is a metric, a threshold, a window (60 minutes by default), and an action. A guard breaches when the measured value is at or above its threshold inside the window; the action then fires automatically. Use Evaluate now to run the rule against current data on demand and see whether it would breach, before you rely on it.
Metrics: crash rate, ANR rate, error rate.
Actions: pause (stop giving the release to new devices), roll back (revert devices that have it), or alert (notify without changing the rollout).
The client-side crash-loop guard#
Independently of server guards, the SDK protects a device that can crash before it can even report. A newly applied bundle must prove itself healthy within a short window (about ten seconds); if the app crashes on boot first, the device automatically reverts to the previous bundle on the next cold start. It will retry a small, fixed number of times and then pin the factory bundle shipped in the binary — so a device can never be bricked by a bad OTA release, even with no network. Each automatic revert is reported back as a rollback with a crash-loop reason.
Targeting#
Targeting rules gate a release to a population before it goes wide. Rule kinds include geography, app-version range, a user attribute, a segment, an audience list, and lifecycle stage. Previewing a rule estimates how many devices it would match, so you size a canary before you ship it.
When to use it#
Set guards once per app and leave them on — they cost nothing until a release regresses. Reach for targeting whenever you want a staged rollout: ship to a small, well-defined population, watch Health, then widen.
Where the data comes from#
Served by
Ota