Analytics and metrics

Analytics and metrics

Patch records download, ready, applied, and failure events from the client SDK. Use the dashboard and CLI to monitor rollout health.

The client posts events to {apiUrl}/v1/metrics/events. Metrics failures never block the update flow; the SDK queues and retries natively.

Dashboard

The web dashboard is your team's control plane in the browser: apps, deployments, release history, New release (command builder, or .cmpatch upload for React Native), promote/rollback/rollout actions, members, and API tokens.

Under Metrics, drill from apps to deployments for rollups. See Web dashboard for a full walkthrough. Open it at your API URL after install (e.g. https://updates.example.com/).

CLI metrics

Deployment-level metrics

React Native

cmpatch deployment metrics --app MyApp-iOS --deployment Production --format table

Capacitor

cmpatch-capacitor deployment metrics --app MyApp-iOS --deployment Production

Useful for overall adoption and health across all releases in a deployment.

Per-release metrics

React Native

cmpatch release metrics --app MyApp-iOS --deployment Production --label v4 --format table

Capacitor

cmpatch-capacitor release metrics --app MyApp-iOS --deployment Production --label v4

Typical event types include Downloaded, Ready, Applied, Failed, and Active.

What to watch during a rollout

Ready and Applied

Ready means the downloaded artifact is unpacked and the SDK has prepared state for the next session according to the activation policy. Applied means the new update runs successfully and notifyAppReady() confirms it. A Ready update can wait for a restart before it becomes Applied.

Application success rate is Applied / (Applied + Failed). Historical Installed and Success events are included as Ready and Applied respectively; stored events are not rewritten. Apps still on an SDK released before the rename keep reporting Installed and Success, and the server counts them as Ready and Applied. API counter keys remain installed and success for compatibility, while dashboard and CLI labels use the new names.

Failures and rollbacks

Spikes after a release often mean a bad bundle or incompatible native project. Check Debugging and consider rollback.

Active count

How many devices are running a given release label, helps confirm a gradual rollout is progressing.

Monitoring such as Datadog or Sentry

Tools like Datadog or Sentry need extra information to see which OTA release a device has installed. That usually means uploading a source map for each release.

OTA JS ships minified, so without a map your crash tool only shows a wall of names. Upload the map to a tool such as Datadog or Sentry. Keeping a copy on Patch alone does not symbolicate those stack traces.

React Native

You can still attach a map when you publish (cmpatch release create --sourcemap …, or cmpatch release-react --sourcemap-output …). Patch stores it privately under _internal. Apps never download it for OTA, and Patch does not push it to your crash tool for you.

Capacitor

cmpatch-capacitor does not upload source maps. Upload them to your crash reporting tool from the CI job that builds webDir. Any .map files in webDir are included in the release and downloaded to devices; remove them before publishing if needed.

In practice: build the map in the same CI job as the release, then run your tracker’s upload step (for example Datadog’s React Native / datadog-ci flow). Use a version tag that matches how you label that OTA release in RUM or errors.

Example rollout monitoring workflow

release with --rollout-percentage 10
→ watch deployment metrics for 24h
→ increase rollout or promote to Production
→ rollback if failure rate spikes

See Production control for rollout commands.