Running audits & fixes
Once your repos are connected, this is the loop you'll use day to day: run an audit, work through what it finds, ship fixes as pull requests, and keep findings current as your code changes. Everything here is in the web app.
Run an audit
An audit reads your repository and produces findings plus a few architectural suggestions. Open a repository and click the audit button from its page — you choose when to run it. The audit comes in two depths, both available on every plan — Standard (the everyday default the button runs) and Full (the complete catalog, behind the level picker); Audit depth covers what each depth runs and how the per-run level picker works.
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 job to follow its pipeline stage by stage, including its cost ticking up live and settling when it finishes. 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 triage. When your audit finishes, the person who started it gets an in-app notification (the bell, described below).
Browse findings and suggestions
An audit produces observations: findings (something to fix), suggestions (an architectural idea to consider), and the occasional advisory (broader process or CI guidance). Each has a stable ref (HYRAX-42), a priority (P0–P3, P0 most urgent), a category (Security, Correctness, Maintainability, Performance, Architecture, or Operations), and the file locations it touches. Filter and sort by priority, category, or kind to triage by impact. See Findings & suggestions.
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). The run's page reports new this run and re-confirmed separately from the repo's current open total, so "49 last week, 89 this week" reads as accumulation rather than the same measurement doubling.
Fix a finding
Open an observation and click Fix. Hyrax makes the change, verifies it, and opens a pull request for you to review and merge. Spawning a fix does not close the observation — it closes as fixed only when the pull request is merged, and stays open while the fix is in flight. See Fixes.
Dismiss and triage
Not every finding is worth acting on. Dismiss an observation with a reason: False positive, Won't fix, and Out of scope stay closed and won't re-surface; Stale, No longer found, and Other can reappear if the issue is found again. Re-running an audit merges with your existing observations rather than replacing them, so your triage is respected. You can reopen a closed observation at any time.
Revalidate to keep findings current
Use revalidate to re-check existing observations against the latest commit and update their status without generating new findings — a fast, cheap correctness pass after you've shipped work. Re-running an audit also reconciles against what's already there: duplicates merge and dismissed items stay dismissed. Revalidate is available on every plan.
A simple rhythm: run an audit on a regular cadence (weekly, or once per release) and after any major refactor, and use Revalidate between audits to confirm fixes landed.
PR review
PR review is on by default for every repository you connect — Hyrax reviews incoming pull requests automatically — posting a single review comment (updated in place as the PR gets new commits) 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: Todo & notifications
On every plan, two top-bar controls keep the loop running without you polling pages — one for what needs doing, one for what happened:
- Todo — a checklist button in the top bar showing your open count, linking to the workspace Todo page: a prioritized list of what needs attention across your repos, each item with a one-click action. It surfaces things like a repository that hasn't had its first audit, an audit or discovery gone stale, unaddressed critical findings, and fix pull requests that have been open too long. Items clear themselves as the underlying condition resolves — finish the audit, merge the PR — rather than being ticked off by hand.
- Notifications — the bell beside it, 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 bell shows an unread badge and a preview of recent items; opening an item marks it read and takes you to the thing itself.
The two are deliberately separate: the Todo list is derived from the current state of your workspace, while notifications are a record of events as they happened. (Account-level email — billing notices, invites, and the like — 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 → Plan shows the detail — on Paid, 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.