Skip to main content

Analytics and metrics

Analytics and metrics

Patch records download, install, success, 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), 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​

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

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

Per-release metrics​

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

Typical event types include Downloaded, Installed, Success, Failed, and Active.

What to watch during a rollout​

Install rate

High downloads with low installs can indicate install-mode issues, binary version mismatches, or client errors.

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.

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.

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.