Skip to content
gplay
Blog

Monitor Google Play crashes and ANRs from the terminal (or CI)

Omar Tamimi
Creator of gplay

Play Console’s vitals dashboards are fine for eyeballing trends. They’re less good when you want to:

  • Fail a CI job if the new release’s crash rate is 30% above baseline.
  • Post a Slack alert when a new crash cluster affects more than 500 users.
  • Diff this week’s ANRs against last week’s before promoting to production.
  • Have your AI agent triage the top 10 clusters and file GitHub issues.

The Google Play Developer Reporting API exposes all of that — clusters, sample stack traces, user counts, error rates, per-device breakdowns. gplay wraps it as CLI commands.

The commands

Section titled “The commands”
Terminal window
# Crash clusters, last 7 days, top 20 by user impact
gplay vitals crashes query \
  --package com.example.app \
  --time-range LAST_7_DAYS \
  --page-size 20 \
  --paginate


# Full crash report for a specific cluster
gplay vitals crashes report \
  --package com.example.app \
  --cluster-name "crashes/abc123"


# ANR clusters
gplay vitals errors query \
  --package com.example.app \
  --issue-types APPLICATION_NOT_RESPONDING \
  --time-range LAST_7_DAYS


# Performance metrics (startup, rendering, battery)
gplay vitals performance startup \
  --package com.example.app \
  --time-range LAST_7_DAYS

Every command returns minified JSON by default. Add --output table if you’re eyeballing in a shell.

A ten-line CI regression gate

Section titled “A ten-line CI regression gate”

Drop this into a GitHub Actions job that runs an hour after promoting to production:

- name: Fail on crash regression
  env:
    GPLAY_SERVICE_ACCOUNT: ${{ secrets.PLAY_SA_JSON_PATH }}
    GPLAY_PACKAGE: com.example.app
  run: |
    THIS_WEEK=$(gplay vitals crashes query --time-range LAST_7_DAYS \
      | jq '[.clusters[].distinctUsers // 0] | add')
    LAST_WEEK=$(gplay vitals crashes query --time-range PREVIOUS_7_DAYS \
      | jq '[.clusters[].distinctUsers // 0] | add')
    if [ "$THIS_WEEK" -gt $(( LAST_WEEK * 130 / 100 )) ]; then
      echo "Crash-affected users up >30% week over week ($LAST_WEEK -> $THIS_WEEK)"
      exit 1
    fi

That’s it. No third-party observability integration, no Play Console screen-scraping, no waiting for a human to notice.

Slack alerts for new crash clusters

Section titled “Slack alerts for new crash clusters”

Combine vitals crashes query with gplay notify send:

#!/usr/bin/env bash
# alert-new-crashes.sh — run hourly from cron
set -euo pipefail


NEW_CLUSTERS=$(gplay vitals crashes query \
  --package com.example.app \
  --time-range LAST_24_HOURS \
  --output json \
  | jq -c '[.clusters[] | select(.distinctUsers > 500)]')


COUNT=$(echo "$NEW_CLUSTERS" | jq 'length')
if [ "$COUNT" -eq 0 ]; then exit 0; fi


MSG=$(echo "$NEW_CLUSTERS" | jq -r 'map("- \(.name): \(.distinctUsers) users") | join("\n")')


gplay notify send \
  --webhook "$SLACK_WEBHOOK" \
  --message "🚨 $COUNT new high-impact crash clusters in the last 24h:\n$MSG"

Fastlane and gradle-play-publisher have nothing here. This is entirely Play Console territory, and it’s the kind of workflow that never gets built when it has to live in a web UI.

AI agent triage

Section titled “AI agent triage”

Give your AI agent (Claude Code, Cursor, OpenClaw, Hermes Agent, or any of the 12 supported agents) this prompt:

Grab the top 10 crash clusters from the last week for com.example.app. For any cluster over 500 users where the top stack frame is in our own code (not Android framework), pull the full report and file a GitHub issue with the stack trace, user count, and affected devices. Skip clusters that already have an open issue.

Claude Code will chain gplay vitals crashes query → gplay vitals crashes report → gh issue list → gh issue create. Read the output, approve the writes, done.

Time ranges you can pass

Section titled “Time ranges you can pass”

gplay vitals commands accept the same time-range values as the Reporting API:

  • LAST_24_HOURS
  • LAST_7_DAYS
  • LAST_30_DAYS
  • PREVIOUS_7_DAYS (week-over-week comparisons)
  • PREVIOUS_30_DAYS
  • Custom ranges via --start-time and --end-time (RFC 3339 timestamps).

Filtering

Section titled “Filtering”

Every vitals query accepts filter flags for OS version, device model, app version, and country:

Terminal window
gplay vitals crashes query \
  --package com.example.app \
  --time-range LAST_7_DAYS \
  --os-versions 34,33 \
  --app-versions 4.2.1 \
  --paginate

That’s how you isolate a regression to a specific Android version or hardware model, from the terminal, in seconds.

Performance vitals

Section titled “Performance vitals”

Beyond crashes and ANRs, gplay vitals performance covers:

  • Startup latency — cold and warm start, per device class
  • Slow rendering — frozen frames, 16 ms budget breaches
  • Battery drain — background power usage, wakelocks
  • Excessive wakeups

Same JSON-first output, same filter surface, same CI-friendly ergonomics.

Getting started

Section titled “Getting started”
Terminal window
brew install tamtom/tap/gplay
gplay setup --auto
gplay vitals crashes query --package com.example.app --time-range LAST_7_DAYS --output table

Full vitals reference at /reference/vitals/. If you want a ready-made Slack alert setup, install the vitals monitoring skill and ask your AI agent to scaffold it against your webhook.

Tags: