How Remediation Works
Remediation is Hud's agent pipeline that takes a detected production issue, finds its root cause in your code, and opens a pull request with a proposed fix.
From detection to a proposed fixHud already knows which function threw, what the execution context looked like, and how the error rate moved over time. Remediation hands that runtime evidence to a coding agent, which investigates the issue against your actual repository and proposes a change.
You watch the whole thing happen on the issue page. Each step publishes its output as it finishes, so you can read the reasoning before a pull request exists, and you can disagree with it.
The steps in a run
A remediation run moves through five steps:
| Step | What the agent does |
|---|---|
| Root cause | Reads the issue's forensic samples, the origin function, and the surrounding code to explain why the issue happens |
| Validate | Checks the root-cause explanation against the code and the runtime evidence. If it does not hold up, the run returns to root cause and tries again (up to 3 attempts) |
| Plan fix | Decides what change would resolve the root cause |
| Implement | Writes the change |
| Open PR | Opens a pull request on the affected repository |
The run is grounded in two things a code-only agent does not have: the forensic sample captured when the issue fired, and the function-level runtime data for the code path involved. That is what lets the agent name a specific function and a specific failure mode rather than guessing from a stack trace.
What you see on the issue page
The issue page shows three sections. Each one has its own state badge and last-updated timestamp, and each opens a drawer with the full write-up.
What Happened is the issue summary plus the error-rate graph. It exists before any remediation run and is regenerated after each step, so it always reflects the latest understanding.
Root Cause is a short preview of why the issue is happening, with a compact forensics card as supporting evidence. The drawer holds the full root-cause write-up.
Fix is a short preview of the proposed change, the linked GitHub pull request, and the list of changed files. The drawer holds the full fix explanation.
Section states
Root Cause and Fix each show one of four states, driven by the run's per-step progress:
| State | Meaning |
|---|---|
| Pending | The step has not started |
| Generating | The step is running |
| Ready | Content is available, with a timestamp |
| Stopped | The step failed. The drawer shows the reason |
Sections advance on their own as each step finishes. You do not act between steps.
Triggering a run
Remediation is triggered manually today, from the issue page. See How to run remediation on an issue.
An issue can accumulate more than one run over time. The issue page shows the latest run. Earlier attempts are not displayed.
Requirements
- GitHub must be connected, and the affected repository must be reachable. Without it, the agent can still produce a root cause but cannot open a pull request.
- The issue must be eligible for remediation. Issues that are not eligible show the summary and graph only, and Get Prompt to Fix remains available as the manual path.
Giving feedback
Root Cause and Fix each accept a thumbs up or thumbs down plus optional free text. This feedback goes to the team that tunes the agent, so a wrong root cause is worth flagging.
Key terms
| Term | Meaning |
|---|---|
| Run | One pass of the remediation pipeline on one issue |
| Root cause | The agent's explanation of why the issue happens, grounded in your code and the forensic evidence |
| Forensic sample | The execution context Hud captured when the issue fired |
| Origin function | The function where the issue was detected |
| Eligible issue | An issue with enough evidence and code context for the agent to work on |
Questions about remediation? Chat with our support team or email us at [email protected]
Updated about 2 hours ago