Monitor EAS Update Health and Adoption from the CLI

Queries the health of published EAS Updates directly from the CLI, launches, failed launches, crash rates, unique users, payload size, the embedded-vs-OTA user split per channel, and the most popular updates per runtime version, using the same data that powers the update and channel detail pages on expo.dev, exposed in the terminal in human-readable and JSON form. It fits post-publish rollout monitoring and regression detection, but only exposes aggregate metrics, not per-user crash detail or device-level reporting.

Prerequisites are eas-cli installed via npm install -g eas-cli and a login via eas login; channel:insights additionally must run from an Expo project directory since it resolves the project ID from app.json, while update:insights only needs a login. Four commands cover the surface: eas update:list discovers recent update groups, their group IDs, and branch names; eas update:insights <groupId> gives per-platform launches, failed launches, crash rate, unique users and payload size with a daily breakdown; eas update:view <groupId> --insights appends the same metrics to standard update-group details; and eas channel:insights --channel <name> --runtime-version <version> gives embedded/OTA user counts, most popular updates, and cumulative metrics for a channel plus runtime. All four support --json --non-interactive for programmatic parsing.

Discovering a group ID before querying insights uses eas update:list with --branch <name> or --all, always passing --json --non-interactive when scripted since omitting a branch/--all flag otherwise prompts for a branch selection interactively:

eas update:list --all --json --non-interactive | jq -r '.currentPage[0].group'

The JSON response's currentPage array has one entry per update group (both platforms of the same publish collapsed into one entry), carrying branch, message, runtimeVersion, group, platforms, and isRollBackToEmbedded, plus codeSigningKey and rolloutPercentage only when those features are in use; calling with --branch <name> also returns the branch's name and id at the top level.

eas update:insights <groupId> shows launches, failed launches, crash rate, unique users, launch asset count, and average payload size per platform (iOS, Android), plus a daily breakdown of launches and failures. Its flags: --days <N> (default 7, mutually exclusive with --start/--end), --start/--end for an explicit ISO date range, --platform <ios|android> to filter a single platform, --json (implies --non-interactive), and --non-interactive for scripting. Its JSON top level carries groupId, timespan, and a platforms[] array, each entry with updateId, a totals block (uniqueUsers, installs, failedInstalls, crashRatePercent), a payload block (launchAssetCount, averageUpdatePayloadBytes), and a daily[] time series of { date, installs, failedInstalls }; the full schema is documented in references/update-insights-schema.md. The health-relevant fields are crashRatePercent (computed as failed installs divided by total installs times 100, zero when there are no installs), installs/uniqueUsers for adoption, and the daily[] series for spotting a sudden spike in failures. Errors include a group-not-found message, a platform-not-published-for-this-group message, and a deprecated-CLI-field message resolved by npm install -g eas-cli@latest.

eas update:view <groupId> --insights extends the standard update:view output with the same per-platform insights inline, with --days/--start/--end flags applying only when --insights is set (passing them alone errors), and without --insights the command behaves exactly as before with no JSON shape change for existing consumers.

eas channel:insights --channel <name> --runtime-version <version> must run from an Expo project directory and requires both flags; it also accepts --days (default 7), --start/--end, and --json/--non-interactive. Its JSON top level carries channel, runtimeVersion, timespan, embeddedUpdateTotalUniqueUsers, otaTotalUniqueUsers, a mostPopularUpdates[] array ranked by unique users, cumulativeMetricsAtLastTimestamp[], and chart-shaped uniqueUsersOverTime/cumulativeMetricsOverTime objects, documented fully in references/channel-insights-schema.md. A stated caveat: mostPopularUpdates[] is only the top-N the server returns, so otaTotalUniqueUsers, a sum over that list, may undercount total OTA reach if more than top-N updates are active. Errors cover an unknown channel name and an empty mostPopularUpdates meaning no OTA update has launched yet for that channel and runtime, usually meaning the channel is still serving the embedded build only.

Four common workflows are given verbatim: verifying a just-published update is healthy by grabbing the latest group ID on production, waiting for adoption time, then checking crash rate per platform and watching for sudden spikes or asymmetric platform behaviour; comparing adoption between two channels by looping channel:insights over them and comparing embedded vs OTA counts and top update; detecting a rollout regression in the last 24 hours by filtering update:insights --days 1 for a crash rate above 1%; and summarizing group metrics for release notes via eas update:view "$GROUP_ID" --insights --days 30, giving human-readable group details plus 30 days of launches/failures suitable for a changelog or incident review.

Output tips: pipe JSON through jq since payloads are structured for easy filtering; --json implies --non-interactive but passing both explicitly is scripting-friendly; daily[].date values are UTC ISO timestamps rendered as YYYY-MM-DD in the human-readable table; and the CLI table labels "Launches"/"Crashes" while JSON uses installs/failedInstalls for the same fields.

Stated limitations: unique-user counts across platforms may double-count a user who runs the same publish on both iOS and Android, and the same applies to otaTotalUniqueUsers as a sum over mostPopularUpdates; a fresh publish may show zeros briefly while the metrics pipeline catches up; installs count downloads, not confirmed launches, since a confirmed run only registers on the user's next update check (typically up to 24 hours later depending on the app's update policy), so metrics lag real-world state slightly; and crashes are self-reported, counting updates that errored during install/launch and were reported on the next update check, so a crash that doesn't trigger a new update request (such as a process kill before recovery) won't appear.

Use it to assess the health or adoption of a published EAS Update: crash rates, install counts, unique users, bundle size, or the embedded-vs-OTA split on a channel, or for post-publish rollout monitoring and regression detection. Skip it when the user needs per-user crash detail or device-level reporting, since this only exposes aggregate EAS metrics.

Input is an update group ID, branch name, or channel name plus runtime version. Output is human-readable or JSON per-platform launch/crash/adoption metrics, a daily time series, and, for channels, embedded-vs-OTA user counts and the most popular updates ranked by unique users.

Wraps the eas-cli tool's update:list, update:insights, update:view --insights, and channel:insights commands, drawing on the same backend data that powers expo.dev's update and channel detail pages; full JSON schemas are documented in references/update-insights-schema.md and references/channel-insights-schema.md.

Teams running EAS Updates who need to verify a rollout is healthy, compare adoption across channels, detect a crash-rate regression, or summarize update metrics for release notes.