How Hud works
Hud's runtime code sensor counts every call to every function in your backend services and learns each one's baseline. Hud brings that runtime context to every rollout, from PR to fully deployed.
Before the merge: Hud checks the change
The diff shows what changed. Hud shows what it will touch in production: which functions, how much traffic they carry and what calls them.
- Hud's PR risk check comments a verdict on each PR: Safe to merge, Review required or High risk. It runs on Claude through your own AI provider account (Anthropic or Amazon Bedrock).
- Policy approval can make that verdict a required check before a PR merges.
- While it writes the change, your coding agent can pull the same runtime context over Hud MCP.
As it takes traffic: Hud watches every function
Within minutes of a new version going out, Hud compares every function with its baseline, including the ones the new version changed. It also flags a function that starts throwing a new kind of exception, even one your code catches. Each function comes back within its baseline or flagged, with no thresholds to write.
- Issues after a rollout name the function where the regression started.
- Alerts arrive in Slack, and issues show in the web app.
When a function regresses: Hud has the evidence
Hud has already captured the forensics: the call graph, the request's URI and parameters, and, for errors, the exception with its stack trace.
- Start Auto Remediation from the issue. An agent finds the root cause, checks it against the evidence, writes the fix and opens a PR.
- Or use Prompt to Fix to hand the issue to your own coding agent over Hud MCP.
- The fix goes through the same PR check as any other change.
In your editor and between rollouts
Hudders show each function's runtime context right above it in your editor. Between rollouts, Hud also flags slowdowns over time and breaches of the SLO rules you set.
Updated 8 days ago

