Ship EAS Updates to a Few First, and Halt Automatically on Crash Rate

Layer two: let crash-free rate decide expand or halt

Pull the recent crash-free session rate from your crash tooling (Sentry or Crashlytics) API, and decide mechanically with thresholds. The script below simply returns its decision on stdout. Run it on a schedule from CI and issue the next command based on the result.

// scripts/rollout-decision.ts
type Metrics = {
  crashFreeRate: number;  // 0..1
  sessions: number;       // measured sessions
};
 
const BASELINE = 0.995;   // normal crash-free rate
const MIN_SESSIONS = 200; // below this, hold (sample too small)
const DROP_LIMIT = 0.01;  // a 1-point drop vs normal is dangerous
 
function decide(m: Metrics): "expand" | "hold" | "rollback" {
  if (m.sessions < MIN_SESSIONS) return "hold";          // not enough sample
  if (m.crashFreeRate < BASELINE - DROP_LIMIT) return "rollback";
  if (m.crashFreeRate >= BASELINE) return "expand";
  return "hold";                                          // wait and see
}
 
const metrics = await fetchCrashFreeRate({ window: "30m" });
const action = decide(metrics);
console.log(JSON.stringify({ action, ...metrics }));
process.exit(action === "rollback" ? 2 : 0);

Keeping the decision to three options is the trick. A binary "expand or halt" wrongly halts or expands in the small-sample early window. Inserting hold lets you stay put until data accumulates. Setting the exit code to 2 only for rollback lets CI branch into "republish the last good update."

# CI example: decide -> on rollback, republish the previous update
node scripts/rollout-decision.ts || {
  echo "Danger signal detected. Reverting to the previous update."
  eas update:republish --branch production --group "$LAST_GOOD_GROUP_ID"
}

There is a pitfall here. Right after publishing, the sample is extremely small and a single crash swings the rate wildly. Running without MIN_SESSIONS makes you over-rollback on the first crash. Early on I forgot the sample floor and reverted harmless updates again and again. The sample floor is a humble but crucial setting that directly drives automation stability.

Layer three: detect crash loops on the device and revert to embedded

Halting delivery on the server cannot save devices that already received the bad update. So put a safety net on the device too. If it crashes repeatedly after applying an update, drop that update and fall back to the bundle embedded in the build.

// lib/update-guard.ts
import * as Updates from "expo-updates";
import AsyncStorage from "@react-native-async-storage/async-storage";
 
const KEY = "update.launchProbe";
const LIMIT = 2;  // consecutive-crash threshold
 
// call very early in startup
export async function armLaunchProbe() {
  if (Updates.isEmbeddedLaunch) return;          // no need to watch embedded launches
  const raw = await AsyncStorage.getItem(KEY);
  const count = raw ? Number(raw) : 0;
  if (count >= LIMIT) {
    await AsyncStorage.setItem(KEY, "0");
    await Updates.rollbackToEmbeddedAsync();      // revert to embedded and restart
    return;
  }
  await AsyncStorage.setItem(KEY, String(count + 1)); // increment before "safe launch"
}
 
// call once init finishes safely (= proof of a successful launch)
export async function disarmLaunchProbe() {
  await AsyncStorage.setItem(KEY, "0");
}

The mechanism is simple. Increment a counter early in startup, and reset it to 0 once init completes. If it crashes mid-init, the counter stays elevated. When that happens LIMIT times, the update is judged "cannot launch on this device" and we revert to the embedded bundle. Excluding embedded launches with isEmbeddedLaunch is mandatory; otherwise the watch keeps running on the reverted bundle too.

Start thresholds conservative

The BASELINE (normal crash-free rate) and DROP_LIMIT (allowed drop) above have different optimal values per app. I recommend placing these thresholds conservatively at first (biased toward halting). A wrong halt recovers in minutes via republish, but a missed halt sends a bad update to everyone, and the experience until you revert is badly hurt.

While operating, collect one to two weeks of your real normal crash-free rate, look at the distribution, and tune BASELINE to actual data. When you run monitoring solo, like indie development, set thresholds that "fall to the safe side even when no one is watching," so you can sleep through a nighttime rollout. In that case, do not crank sensitivity too high either — keeping a generous hold band is the realistic choice.

The three layers only work together

Each layer alone leaves a hole. Canary alone still spreads damage if the halt decision lags. Auto-decision alone cannot save already-served devices. The device net alone does not stop delivery, so new recipients keep growing. Stacking all three is what finally confines a bad update to "few people, short time, self-healing."

For order of adoption, I personally recommend starting with layer three (the device net). Server automation takes time to tune thresholds, but the device net is just added code and prevents the worst case (everyone unable to launch) from day one. What pays off in production is not the flashy automation but this humble move.

Layer one's rollout percentage is a standard EAS feature you can use today at no extra cost. Just ship your next update at --rollout-percentage 5. That alone takes a lot of the fear out of OTA.