docs(autofix): clarify when Autofix runs automatically

[sentry-junior]

DESCRIBE YOUR PR

Replaces the confusing single sentence about "highly actionable" and "high medium or above fixability score" in the Autofix docs with a structured section that clearly explains:

• The four requirements for automatic triggering (automation enabled, 10+ events, 14-day recency, sufficient fixability score)
• What the fixability score is and how it's generated by Seer's ML model
• The four score tiers (Low / Medium / High / Very High) and what each one unlocks (no auto-trigger → root cause only → code changes → open PR)
• How the user-configurable stopping point caps automation depth

Context: the previous wording was unclear about what "highly actionable" and "high medium or above fixability score" meant. This rewrite is based on reviewing the Seer source code (AutofixabilityModel, FixabilityScoreThresholds, trigger.py, issue_summary.py).

IS YOUR CHANGE URGENT?

• Urgent deadline (GA date, etc.)
• Other deadline
• None: Not urgent, can wait up to 1 week+

PRE-MERGE CHECKLIST

• Checked Vercel preview for correctness, including links
• PR was reviewed and approved by any necessary SMEs (subject matter experts)
• PR was reviewed and approved by a member of the Sentry docs team

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
sentry-docs	Ready	Preview, Comment	May 12, 2026 7:10pm

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
develop-docs	Ignored	Preview	May 12, 2026 7:10pm

[ryan953]

I think we will proceed up to these stopping points based on the score, but if the users preference is for less then we'll stop earlier.

Example: say the user has set "Automation Steps: Stop after Plan"

• if the score is 0.99 then we'll do Root Cause and Planning, but not PR create because the user limits it.
• if however the score was 0.50 then we'd do the Root Cause Step, but not go on to do a Plan, because the score is too low.

That's my understanding anyway.

---

Also, the labels in here don't match with the product. In product we've got:

• Stop after Root Cause
• Stop after Plan
• Stop after PR Drafted

[sfanahata]

I'm not sure we need to provide this level of detail unless we expose the score. @ryan953 - do we plan to share any further detail about a fixability score or the fixability confidence of an issue in the autofix UX?

[ryan953]

i think also fixability score is kind of being replaced by the night-shift thing? idk. we probably shouldn't be so specific because its outside the control of users, and will likely change.

for example, i would love for the 10 event minimum to change so i can get automatic fixes for flakey tests sooner

[ryan953]

@cursor fixup this section based on the thread here

[cursor]

I've revised the fixability section based on the review feedback. Here's what I changed:

Removed:

• Specific score thresholds (0.40, 0.66, 0.78) that aren't exposed to users and may change
• Technical implementation details about the ML model's scoring system

Added:

• Clearer explanation that user automation preferences act as a maximum cap
• Correct product terminology: "Stop after Root Cause", "Stop after Plan", "Stop after PR Drafted"
• Examples showing how fixability confidence and user settings interact

Key improvement:
The section now explains that even with high fixability confidence, user settings limit how far automation proceeds—and conversely, low confidence may stop automation early even if settings allow more steps.

The changes have been committed and pushed to the branch. The revised section is more general, user-focused, and won't require updates when internal scoring thresholds change.

  

[sfanahata]

Looks to be in decent shape now.

[sfanahata]

@ryan953 and lingering concerns or requests about what we write here?