OtaKitHow to monitor Capacitor OTA update success
An update you cannot see is an update you cannot trust. How to monitor Capacitor live updates in production — download and apply events, failure signals, and the metrics that should gate a rollout.
Shipping an update you can't observe is shipping blind. The whole point of over-the-air updates is speed and safety, and safety depends on knowing whether the last release actually landed — downloaded, activated, and booted — or quietly failed on a slice of devices. This guide covers what to monitor for Capacitor live updates and how to wire it up with OtaKit.
The single most important signal is the ratio of updates applied to updates that rolled back or failed. If that ratio moves the wrong way after a release, you have a bad bundle in the wild — catch it before it spreads.
The events worth tracking
The plugin emits lifecycle events you can subscribe to and forward to your analytics or logging backend:
import { OtaKit } from '@otakit/capacitor-plugin';
OtaKit.addListener('updateAvailable', (info) => track('ota_available', info));
OtaKit.addListener('downloaded', (info) => track('ota_downloaded', info));
OtaKit.addListener('downloadFailed', (info) => track('ota_download_failed', info));
OtaKit.addListener('updateApplied', (info) => track('ota_applied', info));
OtaKit.addListener('rollback', (info) => track('ota_rollback', info));Send these wherever you already collect product analytics. The names map to the delivery lifecycle: available → downloaded → applied is the happy path; downloadFailed and rollback are your alarms. Full details in Events.
Failure inspection
When a device does roll back, you want to know why. getLastFailure() returns the reason the last update attempt was rejected — a hash mismatch, a missing notifyAppReady(), or a runtime-version incompatibility — so you can distinguish “bad bundle” from “bad network.”
The metrics that should gate a rollout
- Apply rate — of devices that saw the update available, how many successfully applied it. A healthy release climbs steadily.
- Rollback rate — should be near zero. Any spike after a release is your signal to halt promotion.
- Download failure rate — a proxy for bundle size and network fit; persistently high means consider delta updates.
Pair monitoring with staged rollouts. If you release to a small channel first and watch these signals before promoting, a bad bundle is a non-event — see staged rollouts.
Where to go next
See Plugin API for getState() and getLastFailure(), and debugging OTA updates for turning a bad signal into a fix.