bugwatch docs

Agent workflows

For agents: the prompts below are available over MCP via prompts/get (fix_issue, triage, release_check). They only orchestrate tools you already have; the key ones are get_fix_context, search_issues, get_stats, get_release_health, and query_performance. Example: get_fix_context(org="acme", project="checkout-api", shortId=42).

Built-in prompts

The server ships three prompts. Their text is reproduced here so you can paste it into any agent, MCP or not. Arguments are org, project, and (where noted) shortId or version.

fix_issue (org, project, shortId)

Fix Bugwatch issue #{shortId} in project {org}/{project}.
1. Call get_fix_context(org="{org}", project="{project}", shortId={shortId}) and read the in-app frames, source context, breadcrumbs, and release/commit.
2. Locate the failing code in this working tree (match file paths and functions from the frames; the release's commit tells you which revision to compare against).
3. Explain the root cause in two sentences before changing anything.
4. Make the smallest correct fix, add or adjust a test that would have caught it, and run the project's tests.
5. In the commit or PR description, reference the issue link from get_fix_context so the deploy of that release resolves it.
Do not call resolve_issue yourself; resolution is tied to the release that carries the fix.

triage (org, project)

Triage the unresolved issues in {org}/{project}.
1. search_issues(org="{org}", project="{project}", status="unresolved", limit=25), then get_stats(dataset="errors", since=24, interval=60) for the volume trend.
2. Rank by users affected, then events, then recency. Flag anything that first appeared in the last 24h as NEW.
3. For the top 5, call get_issue and note the culprit and release; group issues that share a culprit.
4. Produce a table: rank, #id, title, impact, first seen, recommended action (fix now / ignore with reason / watch).
Only call ignore_issue or resolve_issue after a human confirms; list the exact calls you would make.

release_check (org, project, version)

Assess release {version} of {org}/{project}.
1. get_release_health(version="{version}") for crash-free rate and session counts.
2. search_issues(status="regressed") and search_issues(sort="first_seen", limit=25); keep issues whose first seen is after the release's deploy (list_releases shows the deploy time).
3. query_performance(since=6) and compare p95/failures against the previous window (since=24).
4. Verdict: healthy / watch / roll back, with the three strongest data points and the deep links.

Recipes

Fix the top new issue

  1. search_issues(org, project, status="unresolved", sort="first_seen", limit=5) — newest first.
  2. get_fix_context(org, project, shortId) — read event.exceptions[].frames[] (file, function, line, context, pre, post), event.breadcrumbs, release.commitSha, issue.impact, and similarResolved (issues of the same exception type this project already fixed).
  3. Patch, test, open a PR whose description contains the issue link. Leave the status alone; a human or the release flow resolves it.

Weekly triage

Run the triage prompt, then apply the confirmed decisions in one call: bulk_update_issues(org, project, shortIds=[12, 15, 19], status="ignored") (up to 100 ids; event:write, audited). Post the table to Slack yourself — Bugwatch's channels carry alerts, not reports.

Is this release healthy?

release_check covers it. Two things to know: get_release_health only has data if the SDK sends sessions (mobile and browser do by default; servers usually do not), and query_performance failures count transactions whose status is not ok.

Rotate a leaked DSN key

  1. create_key(org, project, label="rotated-2026-09") — returns the new DSN.
  2. Deploy the new DSN to the SDKs.
  3. set_key_status(org, project, keyId="<old id>", status="disabled") — ingest rejects the old key with 403 within about a minute (the ingest Worker caches key config for 60 s).

Both calls need project:write. The leaked key cannot be used to read anything; it only lets someone send you events.

Wire Slack alerts

  1. create_channel(org, name="#alerts", config={kind:"slack_webhook", url:"https://hooks.slack.com/services/…"}) — the URL must start with https://hooks.slack.com/; it is stored encrypted and never returned.
  2. create_alert_rule(org, project, name="New issues → Slack", conditions=[{type:"new_issue"}, {type:"regression"}], actions=[{type:"channel", channelId:"<id from step 1>"}], frequencyS=1800).
  3. Optional filters: [{type:"environment", value:"production"}], [{type:"min_level", value:"error"}], [{type:"release", value:"2.*"}].

Projects with no rules notify every org channel on new issues and regressions by default, so step 2 is about narrowing, not enabling. Both calls need alert:write.

Put a service behind an uptime monitor

  1. list_channels(org) — pick who gets paged (or create_channel first; Alerts).
  2. create_monitor(org, name="Checkout API", check={type:"http", url:"https://api.example.com/health", keyword:"ok"}, intervalSeconds=60, regions=["wnam","weur","apac"], channelIds=["<id>"]) — alert:write. The response carries the monitor id and, for {type:"heartbeat"}, the heartbeatUrl the job must curl -fsS when it finishes.
  3. get_monitor_history(org, id, since=24, interval=5) after a while: per-bucket uptime with p50/p95, plus the same numbers per region. list_monitor_events(org, id) is the incident timeline.

Two things to tell a human rather than guess at: intervalSeconds below the plan minimum is rejected with 400 {minIntervalSeconds}, and a monitor that is degraded (some regions failing, fewer than quorum) is not an incident — it never pages. Only down does. Details in Uptime monitors.

Silence a monitor for planned maintenance

pause_monitor(org, id) before the window, resume_monitor(org, id) after; a paused monitor keeps its history and cannot page. Resuming restarts it in pending, so the first result after the window sets the state from scratch — that is deliberate, not a lost check.

What agents must hand to a human

Minting tokens, Stripe checkout or portal, and uploading source-map bundles have no tool by design. Say so and point at the dashboard or sentry-cli (Source maps).