Skip to Content
MergeLoom MergeLoom Docs

Runs, Audit, Code Audit, and Health

The Local Worker UI is the main place to diagnose Self Hosted execution after a job reaches the worker.

Runs

Section titled “Runs”

Open:

http://127.0.0.1:8010/runs

Use Runs for:

  • recent local run history
  • current and previous job state
  • raw support/debug detail
  • worker-side error messages
  • links to audit detail where retained

The Runs page is intentionally more operational than the polished Ticket Audit page.

Live Stream

Section titled “Live Stream”

When a job is active, the worker dashboard can show an Open live stream action.

The live stream can include:

  • provider lifecycle events
  • CLI stdout/stderr chunks where available
  • worker tool activity for API providers
  • setup, validation, and repair progress

Live stream availability depends on provider behavior and retention. It is worker-local for Self Hosted workspaces. Set an explicit retention policy when audit evidence is required for compliance.

Ticket Audit

Section titled “Ticket Audit”

Open:

http://127.0.0.1:8010/audit

Ticket Audit answers:

  • which ticket ran
  • which repository was changed
  • which provider/model path was used
  • which stages ran
  • whether validation passed
  • whether repair or review fixes ran
  • what files and commands were involved
  • why a run completed, blocked, failed, or was cancelled

Use Ticket Audit for engineering and security review of a Self Hosted run.

Code Audit

Section titled “Code Audit”

Open:

http://127.0.0.1:8010/audit/code

Code Audit shows worker-owned line attribution:

  • repositories with MergeLoom evidence
  • current attributed lines
  • historical touched lines
  • pending or failed reconciliation
  • file-level diffs
  • ticket and run evidence for tracked lines
  • JSON/CSV export where plan allows

For Self Hosted, line-level Code Audit evidence is not sent to the controller as the primary system of record.

Health

Section titled “Health”

Open:

http://127.0.0.1:8010/health

Use Health when:

  • the worker is idle
  • provider readiness is unclear
  • storage is misconfigured
  • the worker cannot reach the controller
  • executors are not reporting status

Check Docker or Kubernetes logs alongside the Health page when the UI cannot explain the problem.

Troubleshooting Order

Section titled “Troubleshooting Order”
  1. Controller Audit: did the ticket match intake and route to a job?
  2. Worker dashboard: did an executor start the job?
  3. Live stream: is the job actively running?
  4. Ticket Audit: what stage failed or blocked?
  5. Code Audit: did the expected files and lines get tracked?
  6. Health and container logs: is the worker runtime healthy?

Related pages: