Automations

Daily Sentry Error Fixes

Recurring session that pulls new Sentry errors overnight and opens fix PRs by morning.

SchedulesMCP

AuthorOpulent

CategoryAutomations

FeaturesSchedules, MCP

start it with one message

Use the Sentry connector to pull all unresolved errors from the past 24 hours in [project], sorted by event count. For the top 5 errors, investigate the stack trace and root cause, then start a run for each one to open a PR with a fix and a regression test. Skip errors tagged wontfix or expected-behavior. Post a summary to Slack.

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

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

SlackRead and write Slack conversations in Manus

step 1

Connect Sentry and seed the error-fix playbook

Connect Sentry so Opulent can read issues, events, stack traces, and breadcrumbs. Add GitHub for opening PRs, Linear for tracking, and Slack for the summary.

The fix logic lives in a playbook, a reusable, named set of steps Opulent follows every run. It defines how to prioritize errors, how deep to investigate, and what a good fix PR must include.

Playbook: !sentry-fix

For each top error in the daily queue:
1. Pull the issue, stack trace, and recent events from Sentry.
2. Read the source files the trace points to and the recent git
   history for those files.
3. Identify the root cause in one sentence.
4. Open a PR with the fix, a regression test, and the Sentry issue
   link in the description.
5. If the fix is uncertain, label the PR for review instead of auto-
   merging.
6. Log the pattern and resolution to memory for similar errors.

Tip

Ask Opulent to investigate your codebase and past merged PRs that fixed Sentry errors, then write memory entries for recurring root causes, null checks, N+1 queries, missing error boundaries. These entries are recalled automatically on future runs.

step 2

Create the daily schedule

Set the schedule to run daily at a time that gives reviewers a PR to look at before standup. Attach the playbook so every run follows the same shape.

Pick a Slack channel where the summary lands. The channel keeps the team informed without cluttering individual inboxes.

The sharp edge: auto-fixes on high-frequency errors can generate noisy PRs. Start with the top 3-5 errors per run, and expand only after the team trusts the fix quality.

Schedule: Daily Sentry remediation, [project]
- Frequency: daily at 06:00
- Playbook: !sentry-fix
- Slack channel: #sentry-fixes
- Scope: top 5 unresolved errors from the past 24h, sorted by
  event count
- Skip tags: wontfix, expected-behavior

step 3

What a typical run produces

Each morning, Opulent processes the overnight error queue and opens targeted PRs. A run might process five errors and produce three confident fixes, one uncertain fix flagged for review, and one skipped as expected behavior.

Each PR includes the Sentry issue link, a one-line root cause, the fix, and a regression test that would have caught the original error.

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 transfers; CheckoutReceipt.tsx:34 destructures without a
   null check.
   PR #612: Add null safety, show "Bank Transfer" fallback.

2. TimeoutError: Query timeout after 30s on /api/invoices (743
   events)
   Root cause: N+1 query in InvoiceService.getMonthly().
   PR #613: Add eager loading for line items.

3. RangeError: Maximum call stack size exceeded (412 events)
   Root cause: Circular reference in refund.toJSON().
   PR #614: Break circular ref, add max-depth test.

4-5. Two lower-frequency validation errors, PRs #615, #316,
   both flagged for human review.

step 4

Verify and tune after a week

After a week, review which PRs merged and which needed heavy revision. Adjust the scope: increase the top-N count if fixes are clean, decrease it if they are noisy.

Update memory based on feedback. If a certain error tag or file path consistently produces false positives, add a skip rule or a 'needs-review' label.

step 5

Sharpen the error-fix loop

When a fix pattern repeats, promote it from memory to an explicit rule in the playbook. When a pattern fails, add an eval (an automated test for the run) that checks the playbook would not propose the same bad fix again.

Split schedules by project or team once volume grows, so each schedule stays focused and each reviewer sees only relevant PRs.

The natural chain: when a Sentry error needs deeper investigation before a fix, hand it to Auto-Investigate Datadog Alerts or Debug a Bug Report End-to-End; when the fix requires a broad code change, use Fleet-Wide Maintenance Across Thousands of Repositories.