Watching and debugging a run

Find out what your agents actually did

goobers dashboard [path]

Default port 8081; --port=auto increments from there, --no-open skips launching a browser, --wait-for-daemon waits up to 30s for a daemon that's starting concurrently, --listen overrides the full bind address. Against a live goobers up, the portal serves current state; with no daemon running it serves a standalone read-only service instead, so you can browse a dead instance's history. Both modes read the same journal on disk.

Ten views, and every one below was actually opened against a real run before this page shipped, not inferred from a filename: Overview (what needs attention, live and history, in one ranked feed), Getting Started, Workflows and Workflow detail (a definition's execution graph — click a stage to inspect its fields or raw YAML — plus its configuration warnings and recent runs), Goobers, Gaggle detail (active runs, recent outcomes, and a workflow-topology graph showing each workflow's external connections, like a target repository's read/write access), Runs and Run detail (execution graph, a replay scrubber with chapter markers and idle-gap compression, every stage's outputs and content-digested artifacts, a Key Moments digest ordered by significance, and the full event ledger ordered by durable sequence), Insight, and Errors. Insight needs telemetry configured — without it, the view says so plainly instead of showing empty or fabricated numbers.

The portal reads the journal and telemetry stores; it cannot create or edit a definition. At the pinned tag, the approve/override/ rerun API routes exist and are classified as runtime-mutation capabilities, but no portal view calls them — the UI hands you a copyable CLI command instead. Every intervention on this page is a CLI command for exactly that reason.

goobers status
goobers status --agents
goobers status --watch
goobers trace --follow <run-id>
goobers trace --json --follow <run-id>

status --agents lists only the agentic stages in flight right now, by role and run id, read from the runner's own journals — never a process table, so it can't accidentally match the process asking. It needs no credentials and makes no provider calls, so it's safe to run from inside a container during a deploy window. It refuses --phase/--limit/--watch: the probe reports only the live moment. --json --follow streams JSON Lines instead of text.

This is the closest thing the product has to "logs" — Goobers' own word for it is journal, and there is no goobers logs command.

goobers trace --transcripts <run-id>
goobers trace --transcript=<stage> <run-id>
goobers trace --summary <run-id>
goobers trace --verdicts <run-id>

--transcripts prints every recorded agent transcript for the run — the actual prompts and responses, not just outcomes; --transcript=<stage> selects one. --summary gives run metadata and review verdicts together; --verdicts gives verdicts alone.

gaggles/<gaggle>/runs/<run-id>/: run.yaml (pinned run identity), state.json (atomically-replaced checkpoint), events.jsonl (append-only, monotonic sequence), inputs/ (immutable digested snapshots), and artifacts/ (content-addressed by SHA-256). Every run publishes atomically through a hidden staging directory then a rename; repairs are corrective appends, never edits. Secrets are scrubbed before anything is digested, and goobers journal redact is the one sanctioned edit — itself journaled, with the old and new digests recorded. That makes the journal tamper-evident, not tamper-proof.

jq '.type' gaggles/<gaggle>/runs/<run-id>/events.jsonl
sha256sum -c gaggles/<gaggle>/runs/<run-id>/artifacts/sha256/<digest>

A run's id is its OTel trace id. telemetry.db is a rebuildable rollup projection, never the source of truth — the journal is. goobers stats gives a lifetime summary card, goobers telemetry errors lists failures newest-first, and goobers runs du reports journal disk usage. One negative worth keeping: OTEL_EXPORTER_OTLP_* environment variables have no effect — configure export through instance.yaml's telemetry block or GOOBERS_OTLP_ENDPOINT instead. Exporting spans to a collector is on the product repo .

goobers escalations
goobers escalations show <run-id>

A stopped run parks in one of three states: needs-human is a decision — it assigns a human and waits; blocked-on-sibling is a status that self-heals once the sibling clears; needs-remediation is a status covering repass exhaustion, an identical-diff loop, an infrastructure failure, or a CI-poll timeout.

run cancel asks a live daemon to stop a run it's actively executing — cancels the active stage, tears down the worktree, releases the claim, records aborted. run abort is the offline recovery path: with no daemon running, it finalizes a stuck run's journal directly by appending a terminal event.

goobers claims list
goobers claims release --force <item-id>
goobers workspace reset <repo>
goobers down
goobers reset-rate-limit

claims release --force prints the current holder, age, and expiry before releasing. workspace reset only touches a pinned workspace and refuses while a run holds a live lease. down requests the same graceful drain SIGINT triggers, with no HTTP API or port required. reset-rate-limit clears the hourly run budget without touching runs/ — reach for it before rm -rf, which destroys the run journals along with everything else.