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

Endpoint: GET /v1/projects/:project_id/deploys
Exact shape: /v1/openapi.json?path=%2Fv1%2Fprojects%2F%7Bproject_id%7D%2Fdeploys&method=get
Use query parameters, not a JSON body.
Query/filter concept:
  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" }
  ]
}

Endpoint: POST /v1/projects/:project_id/query-blueprints/:blueprint_id/run
Exact shape: /v1/openapi.json?path=%2Fv1%2Fprojects%2F%7Bproject_id%7D%2Fquery-blueprints%2F%7Bblueprint_id%7D%2Frun&method=post
Blueprint: errors_after_last_deploy
Fetch GET /v1/query-blueprints/errors_after_last_deploy for the allowed params before running it.
Concept fields:
  params: {}

{
  "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" }
}

Endpoint: GET /v1/cases/:case_id
Exact shape: /v1/openapi.json?path=%2Fv1%2Fcases%2F%7Bcase_id%7D&method=get
Use query parameters, not a JSON body.

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 `GET /v1/cases/:case_id 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.

From CI/provider post-deploy automation (GitHub Actions):

- name: Notify Agentry of deploy
  if: success()
  run: |
    curl -X POST https://api.agentry.sh/v1/deploys/ \
      -H "Authorization: Bearer $AGENTRY_PUBLIC_API_KEY" \
      -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\"
      }"

For CI/server-side clients, keep the explicit User-Agent header. Cloudflare’s Browser Integrity Check can return 403 (CF error 1010) for defaults such as Python-urllib/3.x; curl usually passes, but an explicit UA keeps deploy hooks predictable.

Do not emit deploy events from app startup, request handlers, cron routes, or browser/client code. If the repo does not expose CI/provider config, leave an explicit handoff naming the deploy host, required env vars, and the exact post-deploy curl command for the operator to add.

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)