For a more detailed Sentry integration guide, [click here](/enterprise/integrations/sentry). Before creating your schedule, Devin needs access to your Sentry data. 1. Go to **Settings > Connections > MCP servers** and search for **Sentry** 2. Click **Enable** and authenticate via OAuth — this grants Devin read access to your Sentry issues, events, and stack traces 3. Click **Test listing 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](/work-with-devin/mcp). Go to **Settings > [Schedules](/product-guides/scheduled-sessions)** and click **Create schedule**. * **Name**: `Daily Sentry remediation — payments-api` * **Frequency**: Daily at 6:00 AM (so fix PRs are ready before standup) * **Agent**: Devin — this lets Devin spawn a separate session for each error, so fixes run in parallel * **Slack channel**: Select a channel (e.g., `#sentry-fixes`) so your team gets notified when the run completes and PRs are ready for review * **Prompt**: ```txt Daily Sentry remediation theme={null} Use the Sentry MCP to pull all unresolved errors from the past 24 hours in the payments-api project, sorted by event count. Skip errors tagged `wontfix` or `expected-behavior`. For the top 5 errors: 1. Pull the full stack trace and breadcrumbs 2. Find the relevant source files in our repo 3. Identify the root cause 4. Start a Devin session to open a PR with a fix and a regression test, linking the Sentry issue URL in the PR description Post a summary of all errors and their PRs to Slack. If I leave feedback on any of the PRs (e.g., marking a fix as a false positive, requesting a different approach, or approving a pattern), create a Knowledge entry capturing that feedback so future runs handle similar errors correctly. ``` 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: ```txt Learn our error patterns and create Knowledge theme={null} Investigate our payments-api codebase and build Knowledge entries for common error patterns: 1. Read recent merged PRs that fixed Sentry errors — look for patterns in what broke and how it was fixed 2. Check resolved Sentry issues for recurring root causes (null checks, N+1 queries, missing error boundaries) 3. Review our error handling conventions in the codebase — which wrapper classes we use, how we log errors, our retry/fallback patterns For each pattern you find, create a Knowledge entry with a specific trigger (e.g., "TypeError in checkout", "database timeout in reports") and actionable fix guidance. ``` 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. 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. 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 schedules 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: ```txt Analyze Sentry fix outcomes and update Knowledge theme={null} Look at all PRs Devin opened for Sentry errors in the last 2 weeks. For each PR, check whether it was merged or closed. Identify themes and learnings — which fix patterns worked, which approaches were rejected, what types of errors were false positives, and where Devin lacked context. Then update your Knowledge accordingly: create new entries, edit existing ones, or delete entries that led to bad fixes. ```

{title}