DEV Community

Cover image for I replaced 4 Play Console tabs with one terminal command
Yasser's studio
Yasser's studio

Posted on

I replaced 4 Play Console tabs with one terminal command

#android #typescript #cli #devtools

I used to start every morning the same way.

Open the Play Console. Check the releases tab. Switch to the vitals tab. Look at crash rates. Look at ANR rates. Open the reviews tab. Scan for 1-star reviews. Cross-reference everything in my head.

Four tabs. Ten minutes. Every single day.

And I still wasn't sure if I had the full picture.

One command instead of four tabs 

$ gpc status
Enter fullscreen mode Exit fullscreen mode 
App: com.example.app  (fetched just now)

RELEASES
  production   v142   completed    -
  beta         v143   inProgress  10%
  internal     v144   draft        -

VITALS  (last 7 days)
  crashes     0.80% ↓  ✓    anr         0.20% ↓  ✓
  slow starts 2.10%    ✓    slow render 4.30%    ⚠

REVIEWS  (last 30 days)
  ★ 4.6   142 new   89% positive   ↑ from 4.4
Enter fullscreen mode Exit fullscreen mode

Ten API calls fire in parallel. Full picture in under 3 seconds.

Releases by track with rollout percentages. Four vitals metrics with trend arrows showing whether things are getting better or worse. Review sentiment with rating trends.

That's gpc status. It replaced the tab-switching ritual I used to do after every deploy.

Most release tools stop at uploads. This one doesn't.

Fastlane supply pushes your AAB and syncs metadata. That's valuable. But it's only half the story.

After you ship, you need visibility. Is the crash rate spiking on the new version? Did ANR rates jump? Are users leaving angry reviews about the change you just pushed?

Nothing else answers those questions from the terminal. gpc status closes the loop between "I shipped a release" and "here's what happened after."

Ship and monitor from the same tool.

Three workflows where this changes things

1. The morning check 

gpc status --all-apps
Enter fullscreen mode Exit fullscreen mode

Runs the full status check for every app in your profiles. Up to 5 apps, one command. If any app has a threshold breach, the command exits code 6.

This replaced my entire morning Play Console routine. I open the terminal, run one command, and know exactly where everything stands.

2. Watching a rollout in real time 

gpc status --watch 60 --notify
Enter fullscreen mode Exit fullscreen mode

Polls every 60 seconds. Clears the screen before each update. Sends a desktop notification when a threshold is breached or clears.

Leave it running on a secondary monitor during a staged rollout. Your crash rate ticks up past your threshold? You know immediately. Not 30 minutes later when you remember to check the Console.

After the rollout, check what changed:

gpc status --since-last
Enter fullscreen mode Exit fullscreen mode 
Changes since 1h ago:
  Version:    141 → 142
  Crash rate: 1.80% → 0.80% (-1.00%) ✓
  ANR rate:   0.30% → 0.20% (-0.10%) ✓
  Reviews:    4.4★ → 4.6★ (+0.2) ✓
Enter fullscreen mode Exit fullscreen mode

3. Automated health gates in CI

This is where gpc status goes from "nice to have" to "catches problems before users do."

Gate a rollout on vitals:

gpc status --sections vitals
gpc releases rollout increase --track production --to 50
Enter fullscreen mode Exit fullscreen mode

If vitals are breached, gpc status exits code 6 and the rollout never happens. No dashboards. No manual checks. Just a threshold and an exit code.

Post-deploy snapshot:

gpc status --format summary --refresh
Enter fullscreen mode Exit fullscreen mode 
com.example.app · v142 production · crashes 0.80% ↓ ✓ · ANR 0.20% ↓ ✓ · avg 4.6★ · 142 reviews
Enter fullscreen mode Exit fullscreen mode

One line. Add it as the last step in your deploy pipeline. Something to look at when reviewing CI logs the next morning.

Parse specific metrics:

# Get crash rate
gpc status --output json | jq '.vitals.crashes.value'

# Check if all vitals are passing
gpc status --output json | jq -e '[.vitals | to_entries[].value.status] | all(. == "ok")'
Enter fullscreen mode Exit fullscreen mode

The JSON output gives you values, thresholds, trend direction, and status for each metric. Build whatever monitoring logic you need on top.

The details that matter

Thresholds are configurable. The defaults (2% crash, 1% ANR, 5% slow starts, 10% slow render) work for most apps. Override them globally in .gpcrc.json, per-project with gpc config set, or per-run with --threshold crashes=1.5,anr=0.5.

Caching is built in. Results are cached for 1 hour by default. Subsequent runs in the same window cost zero API calls. Force a fresh fetch with --refresh. Read from cache only with --cached.

Section filtering saves quota. --sections vitals skips the releases and reviews API calls entirely. Fetch only what you need.

Exit codes are semantic. 0 means all clear. 2 means usage error. 4 means API error. 6 means a vitals threshold was breached. Your CI knows why something failed without parsing log output.

Quick context on GPC

If you didn't read the first article in this series: GPC is a CLI that maps the entire Google Play Developer API. 204 endpoints. 7 TypeScript packages. 1,845 tests with 90%+ coverage on every core package.

gpc status is one of 40+ commands. But it's the one I run the most.

Try it 

# npm
npm install -g @gpc-cli/cli

# Homebrew
brew install yasserstudio/tap/gpc

# Standalone binary (no Node.js required)
curl -fsSL https://raw.githubusercontent.com/yasserstudio/gpc/main/scripts/install.sh | sh
Enter fullscreen mode Exit fullscreen mode

Then:

gpc auth login
gpc status
Enter fullscreen mode Exit fullscreen mode

Docs | GitHub | Status command docs

Free to use. Code is on GitHub.

What does your post-release monitoring look like? Are you checking dashboards manually, or do you have something automated? Genuinely curious.

Top comments (0)