Review genuinely new staging errors

Why this matters

Volume thresholds create noise in staging. The higher-value question is whether a fingerprint is genuinely new, reappeared after resolution, or began immediately after a deploy. That determination needs bounded case and deploy evidence, not an unrestricted agent with a webhook.

Run the review

Fetch the filtered OpenAPI schema for the cases and deploy reads, then use only their documented query parameters:

GET /v1/projects/:project_id/cases
GET /v1/cases/:case_id
GET /v1/projects/:project_id/deploys

Within the interactive session:

1. Select staging cases first seen in the review window.
2. Compare each fingerprint with the prior-day case window.
3. Fetch details only for genuinely new or reappearing fingerprints.
4. Correlate last_deploy_sha and recent deploy evidence.
5. Separate proven facts from a suspected code cause.

Raw case details may contain user and request data. Minimize what enters the summary and do not copy secrets, tokens, or unnecessary identifiers.

Output format

New staging fingerprints — <UTC window>

<fingerprint>
- first seen / last seen / event count / affected users
- suspect deploy and evidence strength
- top in-app frame and likely owner
- recommended next investigation
- missing evidence

Return the handoff to the reviewer. A human decides whether to notify oncall, suppress noise, change case state, or start a code-fix workflow.

Instrumentation

Trusted server errors use the server-ingest credential:

await fetch("https://api.agentry.sh/v1/logs/", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.AGENTRY_SERVER_API_KEY}`,
    "Content-Type": "application/json",
    "User-Agent": "myapp/1.0",
  },
  body: JSON.stringify({
    message: err.message,
    stack: err.stack,
    environment: "staging",
    release: process.env.APP_RELEASE,
  }),
});

Unattended boundary

There is no versioned staging-notification template. A runner cannot receive an owner key, raw case browsing, generic queries, or messaging authority. If a reviewed case should enter the supported code-fix path, use the exact [email protected] template and its policy gates; it may create a draft PR but still cannot message, merge, deploy, or declare production verification without the required trusted evidence.

Variations

• “Review only fingerprints reappearing after a resolved state.”
• “Compare the hour after a selected deploy with the hour before it.”
• “Limit the review to fingerprints affecting at least five distinct users.”
• “Draft an oncall handoff for a human to review; do not send it.”