Watch · Self-audit

Self-audit

Your app tells you why it's slow, before you have to ask. RepoOps watches its own runtime health (RSS, uptime, cron-tick timing), turns a flap or a climb into a ranked, AI-authored fix, and - opt-in - does the same for your own terminal/build output. A hosted fleet view shows which installs on your team are flapping right now, and every applied fix is measured honestly, never a fabricated win.

See it in motion

Where to find it

  • Localhost: the "Self-audit" section on http://localhost:4000/brain-health.html - a live, read-only card for the latest finding (root cause, tier, narration source), or an honest "no finding right now" empty state.
  • Hosted: repoops.ai/team/runtime-health - which installs in your team's fleet are flapping or wasteful right now, grouped per install.
  • API: POST /api/self-audit/run · GET /api/self-audit (own-runtime) · POST /api/env-audit/run · GET /api/env-audit (terminal/environment).

What it does for you

You'll know why your app is slow, without APM expertise.The self-audit pass reads your own /healthzseries and cron-tick timing, classifies a flap or a climb into a tier, and grounds an AI-authored (or deterministic-fallback) fix in the actual measured numbers - no fabricated metrics, no lever that isn't real.
You'll catch flaky tests and slow builds automatically, if you opt in.Turn on local terminal/log capture and the environment-audit pass names flaky-test, repeated-error-loop, failing-fetch-churn, and slow-build-hotspot patterns from your own build/test output - redacted at write time, before anything touches disk.
You'll see your whole team's fleet health in one place./team/runtime-healthrolls up every connected install's findings, so an eng manager sees which machines are flapping without asking each developer.
You'll trust the numbers, because a win is never invented.An applied recommendation re-samples the flagged metric afterward. If it didn't improve, the ledger says improved:false - it never flips to true just because a fix was applied.

Configure

P0 (self-audit on your own runtime) needs no configuration - it samples on the existing cron cadence and is safe by default. Everything past that is opt-in, and the layers stack independently:

  • REPOOPS_SELF_AUDIT_SCHEDULE=1 - turns on the scheduled (vs. on-demand-only) AI audit pass for both self-audit and env-audit. Default OFF; POST /api/self-audit/run / POST /api/env-audit/run work either way.
  • account-settings.json::terminalCapture.enabled - turns on local log-file capture (P1). Default false. Pair with terminalCapture.logFiles (the list of paths to tail).
  • Claude Code session capture (P3) needs TWO separate opt-ins, not one. This is a genuinely advanced, power-user setting, not a single toggle:
    • REPOOPS_DEEP_CAPTURE=1 (env var) - turns on the underlying transcript extraction used for cost/usage telemetry. On its own, it does not feed anything into self-audit.
    • account-settings.json::terminalCapture.claudeCodeSessions (default false) - the separate, explicit consent to bridge that already-captured content into the environment-audit pipeline.
    Both must be true before a single Claude Code turn is bridged. Turning on deep capture for cost/usage reasons alone never silently enables this.

Use it well

  1. Leave P0 running; check Brain health when something feels off.

    No setup required. If brain-health.html's Self-audit section shows a finding, it's grounded in a real tier change on your own machine - not noise.

  2. Turn on terminalCapture.enabled once you want build/test signal, not before.

    It's local-only and off by default on purpose. Point logFiles at your actual build/test log paths; a redaction-corpus test gate proves secrets never survive the write.

  3. Only enable the Claude Code session bridge if you already run with deep capture on.

    It has no effect unless REPOOPS_DEEP_CAPTURE is also set. Think of it as a second, deliberate decision layered on top of an existing one, not a quick toggle.

  4. Use the fleet view to triage, not to page someone.

    /team/runtime-health is for a weekly glance at which installs are flapping - check the outcome ledger before assuming a past fix is still holding.

Examples

✓
A recycle flap catches itself (Vince)
RSS climbs at 400+ MB/min, the tier flips to red, and the Self-audit section on Brain health names "memory-recycle flap" with a concrete fix - before Vince notices the app feels sluggish.
⚠
Two opt-ins, on purpose (Andy)
Andy already runs with REPOOPS_DEEP_CAPTURE=1 for cost telemetry across client projects. That alone does not start feeding session content into self-audit - he has to separately turn on terminalCapture.claudeCodeSessionsbefore an agent's stuck retry loop gets flagged.

Read more