Automating iOS Crashlytics Triage with Claude Code — A Production Pipeline from dSYM Symbolication to Draft PR

Stage [2]: Webhook ingestion and dedup

I keep the ingest function deliberately small. Firebase Extensions can push Crashlytics events into a Pub/Sub topic; the Cloud Function reads from there, deduplicates aggressively, and only enqueues genuinely new work for Claude.

// functions/src/crashlytics-ingest.ts
import { onMessagePublished } from "firebase-functions/v2/pubsub";
import { Firestore, FieldValue } from "@google-cloud/firestore";
 
const db = new Firestore();
const DEDUP_WINDOW_MIN = 30; // do not reprocess the same issue within 30 minutes
 
export const ingestCrashlyticsIssue = onMessagePublished(
  { topic: "crashlytics-issues", region: "asia-northeast1", memory: "512MiB" },
  async (event) => {
    const payload = event.data.message.json as CrashlyticsPayload;
    const issueKey = `${payload.app.bundleId}:${payload.issue.id}`;
 
    const ref = db.collection("crash_triage").doc(issueKey);
    const snap = await ref.get();
    if (snap.exists) {
      const last = snap.data()?.lastSeenAt?.toDate();
      const minutesSince = last ? (Date.now() - last.getTime()) / 60000 : Infinity;
      if (minutesSince < DEDUP_WINDOW_MIN) {
        await ref.update({
          recurrenceCount: FieldValue.increment(1),
          lastSeenAt: FieldValue.serverTimestamp(),
        });
        return; // skip Claude invocation
      }
    }
 
    await ref.set({
      bundleId: payload.app.bundleId,
      version: payload.app.version,
      issueId: payload.issue.id,
      title: payload.issue.title,
      stackTraceRaw: payload.issue.exception.stack_trace,
      affectedUsers: payload.issue.distinct_counts.users,
      crashCount: payload.issue.distinct_counts.events,
      firstSeenAt: FieldValue.serverTimestamp(),
      lastSeenAt: FieldValue.serverTimestamp(),
      recurrenceCount: 1,
      status: "queued",
    }, { merge: true });
 
    await db.collection("triage_queue").add({
      issueKey,
      enqueuedAt: FieldValue.serverTimestamp(),
    });
  }
);

The 30-minute dedup window matters. Crashlytics emits frequent re-notifications for the same crash hash, and without this gate the Claude API quota will be consumed inside an hour. I started with a 5-minute window and saw a 41% reduction in API calls after widening it to 30 minutes, with no measurable loss of meaningful signal.

Stage [3]: dSYM download and symbolication with atos

With Bitcode deprecated (Xcode 14 and later), the stable path is App Store Connect API plus Fastlane. I run fastlane refresh_dsyms on a daily CI schedule, dropping the dSYMs into gs://wallpaper-crash-pipeline/dsyms/<bundleId>/<version>/<uuid>.zip. At triage time we pull the matching one by image_uuid.

#!/usr/bin/env bash
# scripts/symbolicate.sh
set -euo pipefail
 
ISSUE_KEY="$1"          # e.g. com.dolice.wallpapers:abc123
DSYM_BUCKET="gs://wallpaper-crash-pipeline/dsyms"
 
BUNDLE_ID=$(echo "$ISSUE_KEY" | cut -d: -f1)
VERSION=$(gcloud firestore documents describe "crash_triage/${ISSUE_KEY}" \
  --format="value(fields.version.stringValue)")
 
WORKDIR=$(mktemp -d)
gsutil -m cp -r "${DSYM_BUCKET}/${BUNDLE_ID}/${VERSION}/" "${WORKDIR}/dsym/"
unzip -q "${WORKDIR}/dsym/"*.zip -d "${WORKDIR}/dsym_expanded"
 
python3 scripts/atos_resolve.py \
  --issue-key "${ISSUE_KEY}" \
  --dsym-dir "${WORKDIR}/dsym_expanded" \
  --output "${WORKDIR}/symbolicated.json"
 
gcloud firestore documents update "crash_triage/${ISSUE_KEY}" \
  --update-fields-file="${WORKDIR}/symbolicated.json"
 
rm -rf "${WORKDIR}"

atos_resolve.py is a thin wrapper that shells out to atos -arch arm64 -o <BINARY> -l <LOAD_ADDR> <ADDR> for each frame and writes a Firestore-shaped JSON. Average wall time per issue: 8.2 seconds. When a dSYM cannot be found — typically debug builds from test devices — we set status: "unsymbolicatable" and skip the Claude call entirely. Letting Claude reason over hex addresses produces fluent nonsense.

Stage [4]: Claude Code headless RCA

This is the heart of the pipeline. Claude Code runs in headless mode from GitHub Actions, with a deliberately narrow --allowedTools list. No write tools are passed in — the model can read code, grep, and inspect git history, but cannot edit files. Any modifications happen later, in a human-reviewed PR.

# .github/workflows/crash-triage.yml (core step)
- name: Run Claude Code RCA
  env:
    CLAUDE_API_KEY: ${{ secrets.CLAUDE_API_KEY }}
    ISSUE_KEY: ${{ inputs.issue_key }}
  run: |
    npx -y @anthropic-ai/claude-code@latest \
      --headless \
      --allowedTools "Read,Grep,Bash(git log:*),Bash(git diff:*)" \
      --output-format markdown \
      --output-file ./out/rca_${{ inputs.issue_key }}.md \
      --prompt-file ./prompts/rca_triage.md \
      --context-file ./context/${{ inputs.issue_key }}.json

The prompt template enforces a four-section structure on the output: (1) top three root-cause hypotheses with confidence scores, (2) commits from the last 30 days that plausibly relate, (3) a Swift draft fix, (4) a rollback recommendation (recommended / conditional / not needed). I pin Claude Sonnet 4.6 at temperature 0.2 with a 4,096-token output ceiling.

Across the 67 issues processed so far, the first hypothesis was the actual cause 78% of the time, the correct hypothesis appeared in the top two 91% of the time, and the draft Swift fix was adopted with minor edits 34% of the time. The remaining 66% required a human rewrite, but average reviewer time dropped from 14 minutes (writing from scratch) to about 5 minutes (editing a Claude draft).

Stage [5]: Draft PR creation and Slack handoff

The final stage opens a draft PR with the RCA markdown as the body and sends a Slack message that contains just enough context to decide "now" vs. "tomorrow morning."

// scripts/open-draft-pr.js (excerpt)
import { Octokit } from "@octokit/rest";
 
const issueKey = process.env.ISSUE_KEY;
const rcaBody = await fs.readFile(`./out/rca_${issueKey}.md`, "utf-8");
 
const branch = `crashtriage/${issueKey.replace(/[:.]/g, "-")}-${Date.now()}`;
await octokit.git.createRef({ owner, repo, ref: `refs/heads/${branch}`, sha: mainSha });
 
const pr = await octokit.pulls.create({
  owner, repo,
  head: branch,
  base: "main",
  title: `[crash-triage] ${title} — auto draft`,
  body: rcaBody,
  draft: true,
});
 
await slack.chat.postMessage({
  channel: "#crashlytics-triage",
  text: `🩹 Draft PR opened: <${pr.data.html_url}|#${pr.data.number}> for *${issueKey}*`,
});

I deliberately stop short of auto-merging. The Slack message includes the current Crash-free Users number and the 24-hour growth rate of affected users — enough to triage from a phone screen, but the actual merge always passes through a human review.

Three weeks of operating numbers

What follows is real telemetry from the first three weeks of May 2026. Take them as anchor points for sizing your own setup, not as commitments — your crash mix and team will produce different shapes.

• Issues processed: 67 (22 of them non-fatal)
• Median time, Crashlytics notification to draft PR: 71 seconds (p90: 142 seconds)
• Crash-free Users, iOS portfolio average: 99.74% (was 99.62% pre-pipeline)
• MTTD (Mean Time to Detect): 8 minutes (was 2h 30m)
• MTTR (Mean Time to Resolve): 4h 12m (was 9h 18m)
• Claude API cost: ~$42/month for ~1,400 Sonnet 4.6 calls
• False-positive rate (Claude flagged an unrelated commit): 12%

The MTTR halving is, more than anything, a quality-of-life win. When a crash lands at midnight I no longer have to write code at midnight; I review at midnight, and the actual fix happens with daylight judgment.

Four traps worth knowing before you start

1. dSYM upload failures fail silently. Since Xcode 16, setting Debug Information Format to "DWARF with dSYM File" is not enough on its own — dSYMs only reach App Store Connect via the archives path. Wire Fastlane's upload_symbols_to_crashlytics into your CI and verify daily.
2. Don't dedup on issue title. Two EXC_BAD_ACCESS crashes can have identical titles and entirely different image+offset signatures. The Crashlytics-side issue.id hash is the correct dedup key.
3. Don't feed Claude the full stack trace. Over 100-frame stacks dilute the signal. Filter to frames inside your own bundle ID, and compress SDK internals to the top five lines. RCA precision improved noticeably after I added this filter.
4. Do not auto-merge draft PRs. This is the strong recommendation. Even when RCA confidence is high, Swift fixes have side-effect surface area that human review catches. At 17 issues per week, gating on a human reviewer is well within scaling capacity and prevents the "one fix introduces a different bug" pattern.

Where to start if you adopt this

You do not need to build all five stages at once. If I were starting again from zero, I'd sequence it like this:

Week one: ship stages [2] and [3] only, with atos output going straight to Slack. That alone moves MTTD from hours to roughly 15 minutes. Week two: add stage [4] and post the RCA report to Slack. Stage [5] (the draft PR) can wait until week three, when you trust the report content.

Before any of this, measure your current MTTD and MTTR for a baseline. Compute it from the difference between Crashlytics firstSeenAt and the GitHub issue createdAt for 30 days of history. Without that baseline, the after-effect tends to feel imagined rather than measured.

Running indie apps for long enough teaches you that quality cost grows faster than feature velocity. Each release adds to the surface area of past code that must keep working, and the cumulative weight of triage gets heavier without you noticing. Aiming Claude Code at the most mechanical part of that weight has, for me, been the single change that bought back the most evening time this year.

The pipeline is not finished — that 12% false-positive number is the next thing I want to lower. If you're working on something similar and have ideas, I'd love to hear them. Thanks for reading.