Review stale or dangerous error suppressions

Find suppressions that are hiding high-volume, high-impact, or recently regressed errors before noise rules mask real incidents.

Updated · published

markdown for agents →

difficulty beginner · time to value 2 minutes · execution on demand
#errors #suppressions #oncall #governance #ops #sentry-alternative

Start from this 

Review current suppressions and tell me which ones are stale, too broad, or hiding errors that recently affected real users.

Why this matters

Suppressions start as a mercy and become blind spots. A broad rule that was safe last month can hide a revenue-impacting regression after a deploy.

What you get

  • Suppression rules with recent matching cases
  • Rules that match too many fingerprints
  • Suppressed cases with user or revenue impact
  • Recommendations to narrow, expire, or remove rules

Walk through it

You

Are any suppressions hiding real problems?

Agent

I’ll list suppression rules and compare them with current open and ignored cases.

Endpoint: GET /v1/projects/:project_id/suppressions
Exact shape: /v1/openapi.json?path=%2Fv1%2Fprojects%2F%7Bproject_id%7D%2Fsuppressions&method=get
Use query parameters, not a JSON body.
Endpoint: GET /v1/projects/:project_id/cases
Exact shape: /v1/openapi.json?path=%2Fv1%2Fprojects%2F%7Bproject_id%7D%2Fcases&method=get
Use query parameters, not a JSON body.
Query/filter concept:
  status: "open"

The output

The agent returns suppressions sorted by risk: broad pattern, recent matches, affected users, and recommended action.

Setting it up

No extra instrumentation required beyond errors. Keep suppression reasons specific so future agents can evaluate intent.

Variations

  • “Expire any suppression that has not matched in 30 days.”
  • “Show suppressed errors after the last deploy.”
  • “Turn this into a weekly oncall hygiene check.”

Related workflows

ops 10 minutes

Review noisy error cases before suppressing them

Inspect real case evidence, propose the narrowest reversible suppression, and require human approval before changing case or alert behavior.

debugging 10 seconds

Find the bugs 5 people hit but no one reported

Surface real errors that affect multiple users but never get filed as tickets. The biggest source of silent churn.

debugging 2 minutes

Rank errors by revenue impact, not raw count

Multiply users-affected by their plan ARR to surface the bugs costing real money. Stop triaging by event volume.

Adapt this workflow in your own agent.

Ask your agent to map the starter prompt to your saved signal map, live events, and the current HTTP API before answering.

Agentry gives coding agents production context from errors, product analytics, and deploys through one HTTP API. Fetch and read https://agentry.sh/install.md completely, then install Agentry's full first-time telemetry baseline in this repository. I authorize device-code login, saving the owner key only to ~/.agentry/credentials.json, creating one Agentry project for this repository, and read-only inspection of shipped source plus hidden CI/provider configuration. Deeply analyze the product's business logic and complete value flow before choosing telemetry. Save the complete source-backed plan and show me its exact contents and hash. Until I explicitly approve that plan or request a replacement, do not edit app/CI source, place runtime/CI credentials, commit, exercise product traffic, start proof, push, or deploy. After approval, I authorize only the reviewed targets: place the required scoped browser/server/CI credentials through the established environment or secret mechanism, preserve existing telemetry, implement and test the baseline, commit it, push that reviewed commit when the shipped CI/provider path requires it, exercise safe proof paths with test/non-customer data, and perform one deployment through the reviewed shipped CI/provider path. Ask first if proof would charge money, contact a third party, change real customer data, or require new external access. After the plan is saved, immediately before every onboarding state-changing POST, GET current onboarding state, perform only its single returned next_action, then read state again; do not batch or infer later stages. Continue until status is verified, installation_complete is true, and next_action is null. Keep all secrets, source snapshots, proof markers, and scratch files outside the repository.

+ Full access
5.5 Extra High
  1. 1. Open your repo in Codex, Claude Code, Cursor etc.
  2. 2. Paste the install prompt.
  3. 3. Your agent reads the install doc and shows you an implementation plan for approval.
← all workflows