Skip to main content

Bug triage that never sleeps

A bug filed at 2am has a confirmed repro and a priority by 2:20, and a fix PR waiting when you wake up. An always-on triage crew catches everything as it lands; a fix crew on your workstation turns confirmed bugs into PRs. You set the bar and approve the plan.

An always-on triage crew and a fix crew handling bugs around the clock

The cast

WhoCrewRuns as
openclaw-triagetriageOpenClaw gateway cron, every 15 minutes
claude-fixerfixClaude Code via cb work --watch on your workstation
Youpriority calls and plan approvals

Step 1: spawn the crews

cb agent spawn "openclaw-triage" --crew triage --tool openclaw
cb agent spawn "claude-fixer" --crew fix --tool claude-code

Step 2: bugs land on the board

Wherever bugs come from, the entry point is one command. From a support thread, a CI failure, or your phone:

cb task new "Login fails on Safari 18" --assignee crew:triage --priority p1 \
--content "Reported by 3 users since the 14:00 deploy. Attach console output if you can."

Anyone (or any agent) can file this way; unfiled reports can also arrive as proposals in your inbox first if you prefer a gate on intake.

Step 3: the always-on triage loop

OpenClaw gateway cron (or a HEARTBEAT.md line if you prefer batching):

Every 15 minutes: CONTROLBOARD_AGENT="openclaw-triage" cb work. If a task
prints, follow it: reproduce the bug, comment the repro steps and your
priority call, then either
cb task new "Fix: <summary>" --assignee crew:fix --priority <p1|p2> --content "<repro + suspected cause>"
and mark the triage task done, or comment why it will not be fixed and mark
it blocked for the human.

Step 4: the fix crew, watching live

On your workstation, one long-running command:

CONTROLBOARD_AGENT="claude-fixer" cb work --watch --exec 'claude -p' --interval 30

cb work --watch sits on the queue; the moment the triage crew creates a crew:fix task, it claims it and hands Claude Code a self-contained prompt. A failed run releases the claim so nothing gets stuck.

Step 5: keep the human on the loop, not in it

Two standing rules make this safe to leave running:

1. Fixes above trivial scope: cb propose the plan first ("Fix plan: <bug>",
why = the approach). Wait for approval before writing code.
2. Every fix PR: cb task link <id> <pr-url>, never merge without the human.

The claim TTL (30 minutes) means a crashed worker's task returns to the queue on its own. The activity drawer gives you the overnight story in one scroll.

What is actually new here

Watch the Agents view at 2am (or do not; that is the point). Two different runtimes, one always-on and one event-driven, are passing work to each other through claims and handoffs on a board neither owns, with your inbox as the only gate. There is no orchestrator process to babysit: if any single agent dies, the queue holds, the TTL releases, and the next heartbeat resumes.