Incident Response

Debug a Bug Report End-to-End

Hand Opulent a bug report with Datadog logs and database access for root-cause analysis.

MCP

AuthorOpulent

CategoryIncident Response

FeaturesMCP

start it with one message

Debug this bug report end to end. Use Sentry to find the most frequent production error in the past 24 hours, pull the stack trace and related logs, query the read-only database replica for relevant data, trace the root cause in the codebase, and open a PR with a fix and a regression test.

Run this in OpulentCopy it, swap the names for your own, and send it.

connected systems

SentryReview errors, analyze root causes, and suggest fixes for rapid issue resolution

GitHubManage repositories, track code changes, and collaborate on team projects

SlackRead and write Slack conversations in Manus

LinearTrack issues, manage projects, and organize workflows across your team

step 1

Connect Sentry and the read-only database

Connect Sentry so Opulent can search errors, read stack traces, and correlate issues with releases. For data bugs, give Opulent a read-only database connection string as a secret, never write access.

The investigation follows a playbook, a reusable, named set of steps Opulent follows every run. Save your team's triage steps as a playbook so every bug report gets the same thorough treatment.

Playbook: !debug-bug

For a bug report:
1. Find the most frequent related error in Sentry for the past
   24 hours (or the window the report names).
2. Pull the stack trace, release tag, and recent events.
3. Query the read-only replica for records that match the
   affected users or behavior.
4. Check git log for changes in the same window.
5. Read the relevant source files and recent diffs.
6. Identify the root cause in one sentence.
7. Write the fix, add a regression test, and open a PR.
8. Post the root cause and PR link to the bug report thread.

Tip

Use a dedicated read replica or an analytics replica for database queries. A slow SELECT on a read replica does not risk production traffic, and it lets Opulent verify the data state directly.

step 2

Send the bug report to Opulent

Paste the bug report into a run with as much context as the reporter gave you: when it started, who is affected, what is wrong, and where. Specifics let Opulent narrow the Sentry time window and query the right records.

The sharp edge: a vague report ('something is broken') leads to a broad investigation. Ask the reporter for the error message, affected plan tier, approximate time, and page or endpoint before starting the run.

Bug report:
"Pro plan users are seeing 'undefined' instead of their company
name on the billing page. This started after last Friday's
deploy (around 2026-02-13 18:00 UTC)."

Instructions to Opulent:
1. Search Sentry for billing-service errors since Friday.
2. Query the read replica: SELECT id, company_name, plan FROM
   users WHERE plan = 'pro' LIMIT 20.
3. Check git log for Friday's deploy changes to the billing page
   or user API response.
4. Fix, test locally, and open a PR.

step 3

Watch Opulent investigate and fix

Opulent searches Sentry and finds a spike in TypeError for the billing service starting at 18:12 UTC. It queries the replica and confirms Pro users do have company names, the data is fine, so the bug is in the code.

It checks the git log and finds a commit that renamed user.company to user.organization in the API response. The billing page still references user.company.name. Opulent updates the component, adds a regression test for both shapes, verifies in the browser, and opens a PR.

Investigation:
- Sentry: TypeError spike in billing-service at 18:12 UTC.
- DB: Pro users have company_name values; data is clean.
- Git: commit a1b2c3d renamed user.company -> user.organization.
- Code: BillingHeader.tsx still uses user.company.name.

Fix:
- Updated BillingHeader.tsx to user.organization?.name ??
  "Your Company".
- Added regression test for old and new API response shapes.
- Verified locally and opened PR #347.

step 4

What exists when the run finishes

A complete run leaves a root-cause analysis and a fix ready for review: a PR with the code change, a regression test, and a description of the root cause and impact; a note on the bug report or Linear ticket with the PR link; and a record of the Sentry query and database check so a reviewer can retrace the reasoning.

The audit trail is the proof-of-work: every claim is tied to a query or a file, so the fix is credible before anyone merges it.

step 5

Sharpen the bug-debug loop

When a bug type repeats, add its detection to the playbook or write it into memory (the notes a run recalls next time). For example, after this run you might save: 'the user API response uses user.organization, not user.company.'

When Opulent cannot reproduce or fix a bug, flag it for a senior engineer instead of guessing. A clear 'needs human' handoff is better than a wrong fix.

The natural chain: when the bug is part of a broader pattern, sweep the codebase with Fleet-Wide Maintenance Across Thousands of Repositories; when the fix needs verification across browsers, use Click-Test Real Product Flows with Computer Use.