Skip to main content
Your Sentry dashboard has 40 unresolved errors. Your Linear backlog has 30 issues in the current sprint — and realistically, you’ll get to maybe five of them today. You could spend the morning triaging each one, reading stack traces, and context-switching between tools — or you could set up automations that triage errors, trace them to source code, and open fix PRs while you focus on design decisions and code review. This guide walks through two templates that cover both sides of that equation: Sentry error triage and fix finds and patches production errors, and 10x engineer picks up your top Linear issue and delivers a draft PR every morning.
Automations work best with projects. A project provides the Dev Container configuration, dependencies, and environment settings that your automation runs against. Both templates in this guide assume you have a project set up for your repository.

​
Sentry error triage and fix

This template queries Sentry for unresolved errors, traces the highest-impact one to source code, applies a fix, and opens a pull request.

​
What it does

The automation runs four steps in sequence:
  1. Triage — Queries Sentry for unresolved issues from the past 24 hours, sorted by event count. Selects the top unassigned issue and extracts the title, error message, stack trace, event count, and affected users.
  2. Root cause analysis — Locates the exact file and line in your repository using the stack trace. Identifies the error category (null reference, type error, unhandled exception, race condition, etc.) and explains the root cause.
  3. Fix — Applies the minimal change needed to resolve the root cause. Adds or updates tests to cover the error scenario. Runs the test suite and iterates until tests pass.
  4. Pull request — Opens a PR with the fix, linking back to the Sentry issue.

​
Prerequisites

  • Ona account with automations enabled
  • Sentry integration configured for your organization
  • A project with a connected repository that reports errors to Sentry

​
Set up the automation

  1. Navigate to Automations in the left panel and click New Automation
Template selection grid showing available automation templates
  1. Select the Sentry error triage and fix template
  2. Under Trigger, the default is Manual. Keep this for your first run — you can switch to a daily schedule later
  3. Under Projects, select the project whose repository reports to Sentry
  4. Click Save

​
Run it

  1. Open the automation and click Run
  2. The execution view shows each step as it progresses:
    • Step 1 queries Sentry and selects an error
    • Step 2 traces the stack trace to your codebase
    • Step 3 applies the fix and runs tests
    • Step 4 opens the pull request
Execution summary showing automation steps You can expand any step to see the agent’s reasoning and the commands it ran: Action logs showing agent output

​
Review the result

The automation opens a pull request with:
  • The fix applied to the affected file(s)
  • New or updated tests covering the error scenario
  • A description linking to the Sentry issue and explaining the root cause
Review the PR as you would any other — check the fix, verify the tests, and merge when satisfied.

​
Tips

  • Start manual. Run the automation a few times manually to build confidence in the results before scheduling it.
  • Schedule daily. Once you trust the output, switch the trigger to time-based (e.g., 0 9 * * 1-5 for weekday mornings at 9 AM UTC).
  • Pair with Sentry to Linear issues. The “Sentry to Linear issues” template creates Linear tickets from Sentry errors. Combined with this template, you get a full pipeline: detect → ticket → fix → PR.

​
10x engineer

This template runs every weekday morning, picks your highest-priority Linear issue, implements it, runs tests, and opens a draft PR.

​
What it does

The automation runs five steps:
  1. Fetch candidates — Queries Linear for issues assigned to you in the current sprint. Sorts by priority (urgent first), then due date. Excludes issues already in progress, in review, or done. Returns the top 5 candidates.
  2. Evaluate feasibility — For each candidate, analyzes the repository to determine if the issue can be implemented end-to-end: clear requirements, contained scope, testable, no external infrastructure changes needed. Picks the first feasible issue.
  3. Implement — Updates the Linear issue status to “In Progress,” then implements the changes following existing code patterns. Writes tests for new functionality and handles edge cases from the acceptance criteria.
  4. Test — Runs the project’s test suite (npm test, go test ./..., or equivalent).
  5. Pull request — Opens a draft PR linking to the Linear issue. Updates the issue status to “In Review.”

​
Prerequisites

  • Ona account with automations enabled
  • Linear integration configured for your organization and your user account
  • A project with a connected repository
  • Issues assigned to you in the current sprint/cycle with clear acceptance criteria

​
Set up the automation

  1. Navigate to Automations and select the 10x engineer template
  2. Under Trigger, the default is Time-based: weekdays at 9 AM UTC (0 9 * * 1-5). Adjust the time to match your morning routine
  3. Under Projects, select the project you want the automation to work on
  4. Click Save

​
Run it

The automation fires on schedule. Each morning:
  1. It picks your top issue from Linear
  2. Implements the change in your repository
  3. Runs tests
  4. Opens a draft PR
Automation details showing execution history and run controls You review the draft PR over coffee. If the implementation looks good, mark it ready for review and merge. If it needs changes, leave comments — the next run will pick a different issue.
If none of the top 5 candidates are feasible (too large, unclear requirements, requires infrastructure changes), the automation stops early and reports why. This is expected — not every issue is automatable.

​
Tips

  • Keep your backlog prioritized. The automation picks the highest-priority issue. If your backlog is unsorted, it may pick something low-value.
  • Use labels to curate candidates. Add a label like good-for-ona to issues that are well-scoped and automatable, then adjust the prompt to filter by that label. This gives you explicit control over what the automation picks up.
  • Start with well-scoped issues. Bug fixes, small features, and refactors with clear acceptance criteria work best. Exclude epics and large issues.
  • Review the draft PRs. These are drafts for a reason — treat them as a starting point, not a finished product.

​
How they connect

These two templates address different parts of the development cycle but complement each other naturally. The Sentry template finds and fixes production errors. If you also use the Sentry to Linear issues template, those errors become Linear tickets. The 10x engineer then picks those tickets up automatically in the next morning run. Together, they create a loop: detect → triage → fix → ship. Production errors get surfaced, tracked, and resolved without manual intervention at each step.

​
Scaling across repositories

The templates above work on a single project and repository. As your usage grows, you can run the same automation across multiple repositories in parallel — for example, scanning and fixing Sentry errors across dozens of repos simultaneously. The number of parallel actions depends on your plan. See Plans and limits for details.

​
Next steps