Find what broke after your last deploy

Why this matters

Every deploy is a chance to break production. Most teams find out from the support inbox an hour later — by then 30 customers have hit the bug, three filed tickets, and you’ve poisoned a feature launch.

Sentry shows you errors. Datadog shows you graphs. Neither tells you which deploy caused the spike without you flipping between four dashboards and a Slack channel.

Agentry stitches errors + deploys + analytics into one timeline. The agent reads your latest deploy SHA, diffs the error fingerprints before and after, and tells you what’s new — in one prompt, in chat, without you opening a browser tab. If you have the repo locally, it can also draft the fix as a PR.

What you get

• A ranked list of error fingerprints that are new or 10x’d since the deploy
• The deploy SHA + commit message tied to each regression
• For the top regression: a one-paragraph root cause + (optional) draft PR

Walk through it

agentry_list_deploys { project_id: "default", limit: 3 }

{
  "deploys": [
    { "sha": "a3f29b1", "branch": "main", "message": "feat: switch to new auth middleware",
      "received_at": 1747353600, "environment": "production" },
    { "sha": "8c11ddb", "branch": "main", "message": "chore: bump deps",
      "received_at": 1747340000, "environment": "production" }
  ]
}

agentry_run_recipe {
  recipe_id: "errors_diff_around_deploy",
  params: { project_id: "default", deploy_sha: "a3f29b1", window_minutes: 60 }
}

{
  "new_fingerprints": [
    { "fingerprint": "f_72ac",
      "error_type": "TypeError",
      "message": "Cannot read properties of undefined (reading 'id')",
      "first_seen_after_deploy_at": 1747353720,
      "event_count_since_deploy": 47,
      "users_affected": 12 }
  ],
  "regressed_fingerprints": [],
  "deploy": { "sha": "a3f29b1", "message": "feat: switch to new auth middleware" }
}

agentry_get_case { case_id: "f_72ac" }

The output

🚨 1 regression after deploy a3f29b1 (23 min ago)
   "feat: switch to new auth middleware"

NEW   TypeError: Cannot read properties of undefined (reading 'id')
      └─ src/middleware/auth.ts:42 (session.user.id)
      └─ 47 events · 12 users · started +2m after deploy
      └─ Likely cause: new middleware sets session=null for unauthed,
         downstream handler doesn't check.

Next: ask your agent to draft the fix as a PR, or `agentry_get_case f_72ac`
      to read the full stack + related events.

Setting it up

Agentry only knows about deploys you tell it about. Post a deploy event on every production release. CI is the natural place — the deploy SHA is already in the environment.

Option A — from CI (GitHub Actions):

- name: Notify Agentry of deploy
  if: success()
  run: |
    curl -X POST https://api.agentry.sh/v1/deploys/$AGENTRY_PROJECT_ID/ \
      -H "Authorization: Bearer $AGENTRY_DSN" \
      -H "Content-Type: application/json" \
      -H "User-Agent: myapp-ci/1.0" \
      -d "{
        \"sha\": \"$GITHUB_SHA\",
        \"branch\": \"$GITHUB_REF_NAME\",
        \"environment\": \"production\",
        \"message\": \"$(git log -1 --pretty=%s)\",
        \"actor\": \"$GITHUB_ACTOR\",
        \"url\": \"https://github.com/$GITHUB_REPOSITORY/commit/$GITHUB_SHA\"
      }"

The User-Agent header is required — Cloudflare’s Browser Integrity Check returns 403 (CF error 1010) for default curl UAs.

Option B — from your app on boot:

// At startup, after env loads
if (process.env.GIT_SHA && process.env.AGENTRY_DSN) {
  await fetch(`https://api.agentry.sh/v1/deploys/${PROJECT_ID}/`, {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.AGENTRY_DSN}`,
      "Content-Type": "application/json",
      "User-Agent": "myapp/1.0",  // REQUIRED — Cloudflare 403s default UAs
    },
    body: JSON.stringify({
      sha: process.env.GIT_SHA,
      environment: process.env.NODE_ENV,
      branch: process.env.GIT_BRANCH ?? "main",
    }),
  });
}

Both work. CI gives you exact deploy timing; app-boot is easier if you don’t control CI.

Variations

• “Compare the last 4 deploys — which one introduced this error?”
• “Show me all regressions across deploys this week, grouped by which deploy caused them.”
• “Did deploy <sha> cause any error to drop to zero? Maybe we accidentally fixed something.”
• “Watch for new fingerprints appearing within 10 minutes of every prod deploy and post to #eng-oncall.” (uses a Routine — see staging-watcher)