HotCodePush
Book a demo
Login

OTA update analytics for every release

Watch adoption climb, read every failure and skip with its reason, and know your monthly active devices.

Get started Install with AI

From the team behind Capawesome, trusted by 1,000+ teams

  • Bitpanda
  • BTC-ECHO
  • Clovis
  • DHBW
  • E.ON
  • EGYM
  • Eyloo
  • FARO
  • King Arthur Baking
  • Leexi
  • LLMBase
  • Logistiko
  • mobile function
  • Planfred
  • SINC
  • snapAddy
  • Tapni
  • Vattenfall
  • Vitruve
  • AppScreens
  • OpenForge
  • Summon Worlds
  • SpeedPay
  • Rechnerhaus
  • World Aquaculture Society
  • Helmholtz

How it works

Every device reports what it did

A release goes out, and the question starts: did it land? The devices answer it, one result each, and the console adds them up.

HotCodePush's over-the-air (OTA) update analytics show what every device did with every release. Without them, a release goes out and nobody knows if it landed; a billing counter is not an outcome. Each device reports its result: applied, failed or skipped with its reason, or rolled back. The console turns the reports into release health per app and channel: an adoption curve, the time to reach most devices, and the automatic rollbacks, the early warning of a bad release.

Read the analytics

A console card titled Results with one bar per result, applied, skipped, failed and rolled back, and the reasons listed under the skipped and failed bars

The proof

Watch a release land

The curve climbs from the first device on, per app and channel. The devices under it are the same ones your invoice counts.

  • Adoption against the devices active that day

  • Skip and failure reasons under the curve

  • Monthly active devices that match the invoice

See the analytics

A release's adoption curve climbing past the 50 and 90 percent marks, with an applied, a failed and a skipped result and their reasons beneath it

The proof

The first sign of a bad release

Devices that roll an update back by themselves are counted per release, so the warning lands before the tickets do.

  • Automatic rollbacks counted per release

  • The signal auto-pause watches

  • Releases side by side

What each chart shows

One column per release showing the automatic rollback rate, five releases low and one spiking release marked paused.

The proof

Know what your fleet runs today

Which releases run right now, how devices split by native build and country, and when an old build can go.

  • Releases, builds and countries today

  • Snapshots of the device registry

  • See when an old build can go

Read it from the API

Three rings for the fleet today, by release, by native build and by country, each with its legend.

From the terminal

The same numbers from the terminal

Pull a release's counts, ask why one device did not update, and read everything as JSON for your own dashboard.

zsh — my-app

$ npx hotcodepush release get --release 43
Number #43
Channel production
Rollout 100%
Devices 1204
Applied 980
Confirmed 953
Download failures 9
Crash failures 3
$ npx hotcodepush device probe --device 6b1e9d37-2f5c-4a80-9c46-d8e3a1f7b259
Channel production, ios
Outcome skipped, device_incompatible (fingerprint), release #43
RELEASE ROLLOUT CONDITIONS VERDICT
#43 100% fingerprint fail device_incompatible (fingerprint)
#42 100% fingerprint pass, binary pass eligible
$ npx hotcodepush statistics get --type updates --period-since 2026-10-01 --period-until 2026-10-31 --json
✓ the same counts as JSON, for a dashboard or an alert of your own

Guarantees

What holds for every chart

Where the numbers come from, and what they share with your invoice.

for charts and invoice
1 count
in app, CLI and console
1 code
update result counts
Exact
are the only source
Devices

Figures as of November 1, 2026.

The field

How the field does it

What each service reports after a release, from the vendors' own pages: usage counters, or the outcome of every update.

Feature HotCodePush Ionic Appflow
Delivery analytics Applied, failed, skipped and rolled back per release, each with its reasons MAU and downloads
Adoption per release An adoption curve per release, with the time to 50 and 90 percent Not in the Appflow Deploy FAQ as of 2026-10-21
Automatic-rollback rate Automatic rollbacks counted per release, the early warning of a bad release A rollback is a console action; no automatic rollback documented

Last verified 2026-10-21.

More features

Three more things every release gets

Each feature has its own page: the mechanism, the specifics, the field compared and the questions teams ask.

  • Attribute targeting

    Labels your app sets choose which devices a release reaches, every condition is checked on the device, and the audience preview counts the reach before you publish.

    See the feature

  • Staged rollouts

    Start a release small, let it widen on the schedule you set, and have it pause itself the moment failures rise, with one command back to the release before.

    See the feature

  • Safety

    Code signing with a key only you hold, verification on the device before anything is applied, and delivery with no server of ours on the path.

    See the feature

FAQ

Analytics questions

From the devices. Each one reports what it did with every update, and the console adds the reports up per release, app and channel. Results are counted exactly; update-check volume and data transfer are approximate by design. What each chart shows
Because a count alone cannot be acted on. A failed update names what went wrong: the download, the verification or a crash on launch. A skipped one names why the device waited, such as battery or a metered network. The app, the console and the CLI print the same reason. Rollouts that pause on failures
Yes. The monthly active devices the console charts are the ones the invoice counts, from the same devices, so finance and engineering read one figure. Update-check volume and data transfer sit beside them, so you see what fair use is measured against. How billing works
Yes. The CLI prints the figures the console shows, and the API returns them, so your own dashboard or an alert can read them on a schedule. API reference
Ask it. The device probe answers for one device, or for an OS and build: which release it would get, or why it skipped, with the condition that failed. The same code shows in the app, the CLI and the console. Troubleshooting
Yes. A device's record lists the releases it checked, applied, confirmed or failed, each with its date and reason, next to the build, channel and labels it reported last. The device command

Know what your next update did.

Free for 1,000 MAU. No credit card.

Get started Book a demo

Questions? Join our Discord or contact us.