Just after the May holidays, the Crashlytics console for my wallpaper app started pinging me five or six times each morning. The overall crash-free rate was sitting around 99.6%, so nothing was on fire, but a steady drip of Velocity Alerts — the ones that fire when crash volume jumps in a short window — is just enough to fog up the morning. I am Masaki Hirokawa, an artist and indie developer who has been shipping iOS and Android apps since 2014. I tried something small: hand the triage step alone to Claude in Chrome, and keep judgment and fixes on my side. After three weeks I wanted to share what changed in the workflow, less as a tutorial and more as honest notes.
Why Triage Only, Not Full Automation
My first instinct was to wire the whole loop together: alert fires, Claude in Chrome opens Firebase, classifies the root cause, and posts a fix suggestion to Slack. I gave that one day and stopped. Crashlytics stack traces often look similar at the signature level but come from very different call paths, and when I asked an AI to make the final call, it kept linking new alerts to unrelated historical issues and reporting them as already known.
After three weeks, the dividing line that worked for me was narrower. Claude in Chrome is allowed to open the Firebase console, find issues tagged with a Velocity Alert, and report each one as a small bulleted summary — counts over the last 24 hours and 7 days, top devices and OS versions, whether the issue is new, and the top three lines of the stack trace. I read those bullets on my phone and decide what to do. Collection and tidying go to the AI; decisions and fixes stay with me.
For an indie developer juggling several apps — in my case more than 50 across twelve years — even the "is this worth opening right now" decision steals a real chunk of the morning. Shaving that thin layer mattered more than I expected.
The Prompt I Actually Use
The prompt I hand to Claude in Chrome each morning has become a fixed three-step shape. Log in to Firebase, open Crashlytics → Issues for the target app (iOS and Android separately), filter to issues with an active Velocity Alert, then summarize each one in the same format:
- Issue title (first class and method)
- Affected users: 24h / 7d
- Top 3 affected devices and OS versions
- First seen: when (new / existing)
- Top 3 lines of the stack trace
- One factual thing I should check next (no speculation)The last line is the one I keep wanting to expand into "and here is the fix." I do not allow it. Speculation creeps in fast, and the value of the bullet collapses. Restricting that line to dashboard-visible facts — "this issue is rising only on iOS 18.4," "first appeared in v2.14" — is what keeps the report trustworthy.
What Got Easier in Three Weeks
The biggest gain was the first 30 minutes of the day going back to me. Before, my morning routine was making coffee, opening the Firebase iOS app, walking through each Velocity Alert across five apps, jotting notes, and deciding what to do. Now Claude in Chrome runs that on my Mac before I am up, and when I sit down the bullets are already there.
A side effect I did not plan for: cross-app patterns are easier to spot. One morning, the same suspected AdMob SDK NullPointerException was rising in both the wallpaper app and the relaxation app at the same time. Reading the two bullet lists side by side made the link obvious in seconds. Before, I would have walked through one app at a time and probably missed it for a day.
A second quieter benefit is the decision log. I keep the AI's bullets and my own call (act / watch / known) in one document. Looking back a week later to ask "what happened to those issues I told myself to watch?" is much faster when both sides of the conversation are written down.
What Did Not Get Easier — And What Got Worse
To be fair, the first week left me unsure whether this was actually saving time. When the prompt was loose, the model reported issues without a Velocity Alert, or got the 24-hour count off by a row. Then I had to cross-check against the real dashboard, which is two steps instead of one.
The most error-prone field was the new-versus-existing tag. Crashlytics shows a first-seen date, but Claude in Chrome would invent a rule like "if first seen within 7 days, call it new." I had to spell it out: only items tagged "New" by Firebase count as new, everything else is existing. Once the rule was explicit, that field stabilized.
The other case where the workflow simply cannot help is Android crashes whose symbols are not deobfuscated. If the ProGuard mapping file has not been uploaded properly, the stack trace appears as a.b.c.d and neither a human nor an AI can do anything with it. That is not the AI's fault — it is a gap in my own ops. It did push me to finally automate mapping uploads, which I should have done a year ago.
If You Use Sentry or Bugsnag Instead
I use Firebase Crashlytics, but the Velocity Alert concept exists in Sentry ("Issue alerts → trigger when events exceed threshold") and Bugsnag ("Spike detection") as well. The bullet structure I share above transfers almost as-is.
If anything, Sentry's UI handles "first seen per release" at a finer grain, so a prompt like "sort by release and only show items spiking in the last two releases" is easier to write. Crashlytics requires opening each issue and reading per-version data by hand, which makes the AI's pass slower. That is a tool choice, not an AI limitation.
What I Kept, What I Threw Out
After three weeks, three rules survived.
First, Claude in Chrome only summarizes issues tied to a Velocity Alert. Having it walk the full Crashlytics dashboard burns tokens and time for little extra signal.
Second, judgment and fixes stay with me. Letting the AI suggest fixes produces plausible-but-wrong proposals often enough that verifying them costs more than it saves. Fix attempts live in a separate Claude on Xcode session, never in the triage prompt.
Third, once a week I re-read the AI's bullets and my own decisions together. If the same issue has been marked "watch" three weeks running, that is a quiet signal it should be fixed. Because the bullets are flat and unemotional, the review stays honest in a way pure human notes do not.
What I threw out: automatic classification of every Crashlytics issue, and auto-posting to Slack. The first accumulated too many small misjudgments to trust. The second created enough noise that I stopped reading the channel. The shape that survived was: hand the AI a narrow observation task, keep the decision design human.
What I Want to Try Next
Next I want to let Claude in Chrome open Firebase Crashlytics and the AdMob dashboard side by side and tell me when a crash spike and an eCPM drop arrive together. This is the continuation of the AdMob mediation work I am writing about elsewhere. Since I taught myself programming over the early internet in 1997, my rule for new tools has been the same — start with the smallest piece that helps, then expand carefully. I plan to keep applying that to Claude in Chrome.
Thanks for reading. If you are wrestling with Crashlytics and AI in your own workflow, I hope these notes are useful.