Skip to main content

Debug a Bug Report End-to-End

Hand Devin a bug report with Datadog logs and database access, and get back a root-cause analysis and fix PR.
AuthorCognition
CategoryIncident Response
FeaturesMCP
1

Connect Datadog

Devin needs access to your Datadog logs to search for errors related to the bug. If you haven’t already, enable the Datadog MCP:
  1. Go to Settings > MCP Marketplace and find Datadog
  2. Click Enable and provide two secrets:
  3. If your Datadog instance uses a custom site (e.g., datadoghq.eu), also set DATADOG_SITE
Once connected, Devin can search logs, pull error traces, and correlate issues with deploys — all from inside the session. See MCP Marketplace for full setup details.
2

Give Devin read-only database access

For data bugs — wrong values, missing fields, broken queries — Devin is dramatically more effective when it can verify the data state directly. Pass a read-only connection string as a Secret:
  1. Go to Settings > Secrets and add a new secret:
    • Name: DATABASE_READ_REPLICA_URL
    • Value: postgresql://readonly_user:password@read-replica.internal:5432/production
  2. Add a note like: “Read-only connection to the production read replica. Safe for SELECT queries only.”
Alternatively, connect a database MCP (PostgreSQL, MySQL, etc.) in Settings > MCP Marketplace — Devin can use either approach to query your data.
Always use a read replica or a user with SELECT-only permissions. Devin never needs write access to investigate a bug. If you’re concerned about expensive queries impacting performance, point Devin at a dedicated read replica or an existing analytics replica that’s separate from your production database.
3

Send Devin the bug report

Paste the bug report directly into a Devin session. Include as much context as the reporter gave you — when it started, who’s affected, what’s wrong, and where. For a structured investigation, use the !triage template playbook — duplicate it and customize the steps for your stack.The more specific the report, the faster Devin finds the answer. “Since Friday’s deploy” lets Devin narrow the Datadog time window. “Pro plan users” tells it exactly which records to query.
4

Devin investigates and fixes

With Datadog and database access connected, Devin runs a full investigation:Pulls Datadog logs — Searches for errors on the billing service since Friday, filtering by service name and error status. Finds a spike in TypeError: Cannot read property 'name' of undefined starting at 18:12 UTC on the deploy date.Queries the database — Runs SELECT id, company_name, plan FROM users WHERE plan = 'pro' LIMIT 20 against the read replica. Confirms that Pro users do have company_name values — the data is fine, so the bug is in the code.Traces the code change — Checks git log --since="2026-02-13" and finds commit a1b2c3d that refactored the user API response, renaming company to organization. The billing page at src/pages/billing/BillingHeader.tsx still references user.company.name.Writes the fix — Updates BillingHeader.tsx to use user.organization?.name ?? 'Your Company' and adds a regression test that renders the component with both the old and new API response shapes.Verifies in the browser — Starts the dev server, opens the billing page in Devin’s built-in browser, and confirms the company name now renders correctly for a test user.Opens a PR with the fix, test, and a description explaining the root cause and impact (all Pro and Enterprise users, ~350 accounts).
5

Follow up

Once the fix PR is merged, you can ask Devin to sweep for related issues or add monitoring:If you want Devin to remember something from this investigation for next time, just tell it — e.g., “Remember that the user API uses user.organization, not user.company.” Devin will propose a Knowledge entry that you can review and save. This way, future sessions start with the context your team has already learned.