Audit sourcemap coverage for minified errors

Find which production errors cannot be unmangled because sourcemaps are missing, stale, or uploaded under the wrong release.

Updated · published

markdown for agents →

difficulty intermediate · time to value 5 minutes · execution on demand
#errors #sourcemaps #releases #frontend #ops #sentry-alternative

Start from this 

Audit sourcemap coverage for current open client-side errors. Which cases still have minified stacks, and which release/source_url pairs need maps uploaded?

Why this matters

Minified stacks turn an easy frontend bug into archaeology. The fastest fix is often not code; it is uploading the missing .map for the right release and source URL.

What you get

  • Open client-side cases with minified frames
  • Which sourcemaps are already uploaded
  • Missing release/source URL pairs
  • A suggested upload command or CI step

Walk through it

You

Which production errors still need sourcemaps?

Agent

I’ll list client-side cases, try local unmangling, then compare against uploaded sourcemaps.

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"
Endpoint: GET /v1/sourcemaps/:project_id/
Exact shape: /v1/openapi.json?path=%2Fv1%2Fsourcemaps%2F%7Bproject_id%7D%2F&method=get
Use query parameters, not a JSON body.

The output

The agent returns a punch list of missing maps. For each top case, it should include release, source URL, and whether local translation succeeded.

Setting it up

Upload sourcemaps after every frontend build. Keep release identifiers consistent between error events and uploaded artifacts.

Variations

  • “Only audit the latest release.”
  • “Generate the CI upload step for Vite.”
  • “Which cases became readable after the last sourcemap upload?”

Related workflows

debugging 2 minutes

Find IE/Safari/old-Chrome-only crashes

Split client-side errors by browser and version. Surface fingerprints concentrated in one engine — usually older Safari or a stale Chromium.

debugging 3 minutes

Investigate errors after the latest deploy

Review cases first seen after a trusted deploy, distinguish SHA attribution from timing correlation, and inspect the highest-impact evidence before proposing a fix.

debugging 10 minutes

Use a redacted session replay as supporting evidence

Inspect one authorized, consented recording around a reported problem, distinguish rendered observations from inference, and avoid treating replay as automatic root cause.

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