Running audits & fixes
Once your repos are connected, this is the loop you'll use day to day: run an audit, decide what each finding deserves, ship fixes as pull requests, and track bigger work as issues. Everything here is in the web app.
Run an audit
An audit reads one repository and reports what it finds. Audits never start on their own: you choose when to run one. There are three places to start it:
- Activity. Open Activity, set Kind to Audits, and click Run audit. (The Start menu on Activity offers Audit too.)
- Code health. The Run audit button sits beside the page title.
- A repository's page. The header's Run Standard Audit button runs a Standard audit in one click. The menu beside it lets you choose Full audit instead, after a quick confirmation.
From Activity or Code health, the Run an audit dialog asks for two things: the Repository, and the Depth:
- Standard: the usual audit. Faster and cheaper.
- Full: every audit tool. Slower, and costs more.
Both depths are available on every plan. Audit depth covers what each one runs.
A repository needs a finished discovery before it can be audited. Until then, the dialog marks it Needs discovery and links to its Discovery tab.
There is no per-month run limit on any plan. Each run draws against your workspace's included credit, and a deeper audit on a bigger repo draws more; Hyrax won't start a job that would run past what you have. See Plans & pricing.
Watch it run
Every job lands on the Activity page, which shows each run's status: Queued, Running, then Completed, Failed, or Cancelled. Open a run to follow its steps one by one, including its cost as it runs and when it settles. The run's Outcome shows how many findings are new this run and how many were re-confirmed. If an audit completes with some of its analysis groups failed, it's marked Partial Completion: the findings from the groups that succeeded are real and ready to work on. When your audit finishes, the person who started it gets an in-app notification (described below).
Read the results in Code health
An audit's results go to Code health, which you open from the rail inside a project or at the workspace. At a project, Code health lists the repositories that project works on; at the workspace, every repository you can see. A repository's own Overview shows its Top findings, with a link to All in Code health.
Code health opens on what needs a decision: open Critical and High findings that no issue tracks, nobody keeps, and no fix is working on. When that list is empty it says so, and Show the rest of the findings widens it to everything open.
- Findings · Suggestions · Advisories switches between the three kinds. Most results are findings. Advisories are broader process or CI guidance. Suggestions appear only for workspaces where Hyrax support has turned them on.
- Filters narrow the list by state (Open or Resolved), Fixed by a Hyrax PR, Severity, Tracked, Kept, Fix running, Repository, and Domain. Easy wins only narrows it to high-priority findings that are cheap and low-risk to fix.
- When Hyrax's fix attempts on some findings ran out, a callout above the list says so; Review shows them.
Each finding has a stable reference (HYRAX-42), a severity, a domain, and the file locations it touches. See Findings & Code health.
Findings accumulate across runs: the number on a repo is cumulative, not per run. Each audit is a deep sampling pass. A re-run re-confirms most of what's already open and turns up some genuinely new findings, so counts naturally rise over time, and two runs of the same depth won't match exactly. That's the intended behavior, not a bug. A run's page reports what that run found; Code health shows everything open.
Decide what each finding deserves
For each finding, pick one:
- Fix it. Click Fix, or select several and use Fix (N). Hyrax makes the change, verifies it, and opens a pull request for you to review and merge. Starting a fix does not close the finding: it closes as
fixedonly when the pull request is merged. See Fixes. - File it as an issue. Inside a project, select findings and click File as issue, then choose One issue for all of them or One issue per finding. The issue lands in that project, and each finding shows Tracked with the issue's reference. Filing is available inside a project, not at the workspace level. See Issues.
- Keep it. Use Keep… when a finding is real but not for now. You own it, you can leave a note, and you pick a look-again date. It stays open, shows in My work under Kept by you, and needs a decision again when that date comes.
- Dismiss it. Dismiss with a reason. False positive, Won't fix, and Out of scope stay closed and won't come back. Stale, No longer found, and Other can reappear if the problem is found again. You can reopen a closed finding at any time.
Re-running an audit merges with your existing findings rather than replacing them, so these decisions stick.
Re-check findings without a full audit
The revalidate job re-checks existing findings against the latest commit and updates their status without looking for new ones. It's a fast, cheap correctness pass after you've shipped work. In the web app it's called Re-check findings:
- Code health. The Re-check findings button sits beside Run audit and asks which repository to re-check.
- A repository's page. Re-check findings is the last item in the menu beside Run Standard Audit.
Findings the current code has fixed close and move to Resolved. If a repository has nothing open, there's nothing to re-check and the option is unavailable. Only one re-check runs on a repository at a time: while one is running, Hyrax won't start another there. Revalidate also runs through the REST API and the MCP server. Re-running an audit also reconciles against what's already there: duplicates merge and dismissed items stay dismissed.
PR review
PR review is on by default for every repository you connect: Hyrax reviews incoming pull requests automatically, posting a review comment at the bottom of the thread on each review (the previous one folds into a short pointer) and a Hyrax Review check run, which you can optionally require for merge. It is available on every plan, and you can turn it off per repo in the repo's settings. See Pull request review.
Stay on top of it: notifications
On every plan, your notifications keep the loop running without you polling pages. They are a per-user feed of what happened in your workspace: a finished audit, a failed job, a fix pull request opened or merged, and billing notices. The top bar marks when something is unread and opens a preview of recent items; opening an item marks it read and takes you to the thing itself. (Account-level email, such as billing notices and invites, sends on every plan; there's no per-run email on any plan.)
Spend controls
Your spending is always visible while you work, on both plans: the Activity page shows every job's cost, the top bar shows the credit you have left, and Settings → Billing shows the detail. On Paid, that's what's pending and when your credit renews; on Free, the remaining balance. Behind the scenes, independent guardrails (a per-job budget cap, your own overage spending limit, and velocity limits) keep a single run or a busy month from surprising you. They're described in Spend controls on the pricing page.