Automatic fixes for Sentry errors

A new error reaches Sentry. Somebody has to read it, find the code, write the fix, open a pull request and get its checks green. There are three ways that happens today, and they stop at different places.

By hand

An engineer triages the issue, reproduces it, writes the fix and babysits the pull request's checks. It works, and it is the work that piles up: when errors arrive faster than anyone can triage them, the backlog is the result.

Sentry's Seer

Seer finds the root cause of a Sentry issue and opens a fix PR for it, inside Sentry, one issue at a time, and it is good at it. Its work ends at the fix PR: the pull request's checks, the pull requests people open and Dependabot's are outside it. Cooper&Wright and Seer, compared.

bugstack

bugstack catches crashes through its own SDK, or through Sentry or Datadog, and opens a small fix as a pull request that runs through your CI. It can merge proven fixes on its own when you allow it. Cooper&Wright and bugstack, compared.

Cooper&Wright

Cooper&Wright reads the new Sentry error, opens a GitHub pull request with the fix, then watches its checks and fixes what fails, round by round, up to three rounds. If the checks are still red after that, it stops and writes down why. It does the same for the pull requests your team opens and for Dependabot's. Nothing merges without you. See one error become a merged PR.

What it needs

Your code on GitHub and your errors in Sentry; the pull request loops need only GitHub. It reads your code through read-only tools and writes only to the pull request branch it is working on. It is free while in beta, with no card. What it reads and writes.