Daily Sentry Error Fixes

For a more detailed Sentry integration guide, click here.

Connect the Sentry MCP

Before creating your automation, Devin needs access to your Sentry data.

Go to Customize > MCPs (Browse marketplace) and search for Sentry
Click Enable and authenticate via OAuth. Review the permissions shown on Sentry’s consent screen before you approve
Click Test tools to verify the connection is working

Once connected, Devin can query your Sentry projects, pull issue details and stack traces, and read breadcrumbs — all from within a session. Learn more about configuring MCP servers.

The Sentry MCP is not read-only. Alongside its retrieval tools, it exposes management tools that can update issue status, assignments, tags, bookmarks, and alerts, and Devin acts with the permissions of the Sentry account you authorize. To limit what Devin can change, authenticate with a dedicated Sentry account whose organization role and team membership cover only the projects this workflow needs.

Create the automation

Navigate to Automations in the sidebar and click Create automation.

Name: Daily Sentry remediation — payments-api
Trigger: Expand Schedule and choose Every day — 6:00 AM (so fix PRs are ready before standup)
Connections: Select the Sentry MCP so each run can pull your errors
Slack channel: Under Notifications, click Add notification > Post to Slack and select a channel (e.g., #sentry-fixes) so your team gets notified when the run completes and PRs are ready for review
Prompt:

Seed Knowledge from your codebase and past fixes

Devin writes better fixes when it understands your app’s error patterns. Instead of writing Knowledge entries yourself, ask Devin in any session to investigate your codebase and past fixes, then let it create the Knowledge:These entries are automatically recalled when Devin encounters matching errors during scheduled runs — and the scheduled prompt above tells Devin to update Knowledge based on your PR feedback, so it improves over time.

What a typical run produces

Each morning, Devin processes the overnight error queue and opens targeted PRs. Here’s what a real session output looks like:

Processed 5 Sentry errors from payments-api (past 24h):

1. TypeError: Cannot read property 'last4' of null (1,892 events)
   Root cause: Stripe webhook delivers `payment_method: null` for
   bank transfer payments. CheckoutReceipt.tsx:34 destructures
   without a null check.
   PR #612: Add null safety to CheckoutReceipt, show "Bank Transfer"
   fallback for non-card payments.

2. TimeoutError: Query timeout after 30s on /api/invoices (743 events)
   Root cause: N+1 query in InvoiceService.getMonthly() — each
   line item triggers a separate product lookup.
   PR #613: Add eager loading for invoice line items with
   Sequelize `include`.

3. RangeError: Maximum call stack size exceeded (412 events)
   Root cause: Circular reference in refund.toJSON() when a
   refund references its parent transaction which references
   the refund.
   PR #614: Break circular ref with a custom serializer,
   add max-depth test.

4-5. Two lower-frequency validation errors — PRs #615, #616.

Each PR includes the Sentry issue link, a description of the root cause, the fix, and a test that would have caught the original error.

Tune and iterate

After a week of runs, review what’s working and adjust:Scope the error count. Start with top 5 errors per run. If Devin consistently produces mergeable PRs, increase to 8-10. If fixes need heavy revision, reduce to 3.Filter by project or tag. Narrow the prompt to specific Sentry projects (payments-api, web-frontend) or exclude noisy tags. You can create separate automations per project if error volumes differ.Learn from results. After a couple of weeks, ask Devin to analyze which fixes actually shipped and turn that into Knowledge: