How to Read Watchtower
Pick the lane, then the page
Atlas stays easier to scan when the route map reads like navigation first. Start with the lane that matches your question, then expand the full page-job model only when you need the deeper contract details.
Operational companion page for when the question is about live health and current status rather than static explanation.
Change pace: Check recent updates first. These pages move when the network or live support surfaces change.
Use Watchtower for what is happening now, then come back to Atlas when you need the why behind it.
Open ArchitectureEntry
Use these pages when you are still orienting and need the safest first click before you pick an owner or system.
Ownership
Use these pages when your real question is who should handle the work, how it moves, or which charter owns the surface.
Systems
Use these pages when you need the map, structure, services, and interfaces behind the network instead of the people or routing rules.
Operations
Use these pages when something feels broken, you need a concrete next check, or you need the live-status companion surface.
Use this page like an interpretation guide, not a live console
I need to know what one tab is showing me
Fastest reading layer — tab-by-tab interpretation before deciding whether anything is wrong.
- Best for
- Overview, Live Event Stream, Bridge Log, Agent Activity, Cost Tracker, and Service Health questions.
- Stop after this when
- Stop once the tab makes sense and you know whether you need the event dictionary or investigation flow next.
Access
Most readers should use Watchtower on the LC Tailscale network at http://main-mini:5175/. Meg's container-era preview mirror on 5181 retired with that stack (2026-09-30 revalidation), so 5175 is the one live Watchtower surface.
Dashboard Views
Watchtower is organized into tabs. Here's what each one shows:
🏠 Overview
At-a-glance network health. Shows the count of healthy/degraded/offline services, recent event volume, and the most active agents in the past 24 hours.
- →Green counts = everything nominal
- →Yellow = service reachable but slow or returning warnings
- →Red = service unreachable or erroring consistently
- →Event spike = high agent activity (usually normal during Scout cycles)
📡 Live Event Stream
Real-time feed of every observability event. New events appear at the top.
- →"service" field — which agent/service produced the event
- →"name" field — event type in dot notation (cycle.completed, bridge.call, recall.query)
- →"level" field — info (routine), warn (degraded), error (failed)
- →"durationMs" — how long the operation took; outliers are worth investigating
- →"meta" — structured payload specific to the event type
- →Use the service filter to watch one agent, level filter to see only warnings/errors
🌉 Bridge Log
All agent-to-agent Bridge conversations. Shows who initiated, who was called, session ID, duration, and message count.
- →High turn count (> 5) = complex advisory loop, usually fine
- →Very short duration + low turns = simple question/answer, check outcome
- →Same session ID appearing multiple times = multi-turn session, filter by it
- →Target: clawdy-advisor = Scout asking Clawdy for direction (expected every cycle)
- →Target: atticus = governance gate check
- →Target: dexter ↔ buzz = Labs coordination (experiment design ↔ distribution)
- →Target: samwise = intake routing or delivery handoff
🤖 Agent Activity
Per-agent summary: cycle count, last active timestamp, event volume, and recent cycle outcomes.
- →"Last active" > 4 hours ago = agent may have missed a scheduled cycle
- →Cycle count growing steadily = healthy autonomous operation
- →All cycles showing "error" = something systemic is broken
- →Scout cycles are the most frequent, expected every 1–4 hours
- →Samwise delivery cycles appear when intake or delivery work is active
- →Dexter and Buzz appear during active Labs experiments — intermittent by design
💰 Cost Tracker
Token usage and imputed cost per agent over time. Pulls from cost.tracking events plus tokens.window metering for fixed-price subscription pools.
- →Daily totals should be stable; a spike usually means a large Codex delegation
- →Scout and Clawdy are typically the top spenders; Labs agents (Dexter, Buzz) spike during active experiments
- →Codex delegations show up as a single high-token event (expected for complex tasks)
- →Z.AI and OpenAI rows show usage by model tier (GLM-5.2, GPT-5.4, Codex)
- →Subscription cost is fixed-price; token totals show pool burn and model mix, not a new per-token bill
- →Zero cost for a long period = agent may not be emitting cost events
❤️ Service Health
Timeline view of each service's health status. Checked by the Monitor service every 2 hours. Services have an expected-state registry (local vs. hosted) so cloud-hosted services show a blue badge instead of a red "Down" alert.
- →Green band = healthy throughout that period
- →Yellow = degraded (reachable but returning errors or high latency)
- →Red = offline (Monitor could not reach the service; expected to be local)
- →Blue badge = hosted externally (e.g., OpenObserve on Railway); offline local endpoint is not a fault
- →Gaps in the timeline = Monitor was not running (container restart, etc.)
- →Consistent red on Recall = QMD is down (high priority)
- →Consistent red on Bridge = agents cannot communicate (critical)
Common Event Types
Events use dot-notation names. Here are the ones you'll see most often:
| Event name | Service |
|---|---|
| cycle.started | scout-* |
| cycle.completed | scout-* |
| bridge.call | currykit-bridge |
| recall.query | currykit-recall |
| rag.sync | currykit-rag |
| delegation.created | scout-* |
| delegation.completed | scout-* |
| governance.proposed | scout-* |
| governance.approved | scout-atticus |
| governance.redirect | scout-atticus |
| monitoring.completed | monitor |
| cost.tracking | any |
| tokens.window | usage-meter |
| currybox.exec | currykit-currybox |
| tts.generated | currykit-tts |
Patterns: Healthy vs. Worth Investigating
✅ Healthy patterns
- →Scout cycle.completed events every 1–4 hours across all projects
- →Bridge calls to clawdy-advisor at end of each Scout cycle
- →Samwise intake/delivery events when Linear activity is active
- →Dexter ↔ Buzz Bridge calls during active Labs experiments
- →monitoring.completed with alerts_detected: 0 every 2 hours
- →Steady trickle of recall.query events across agents
- →Cost tracking events within the normal low per-cycle range for steady routine work
- →All service health bands green overnight with no red gaps
⚠️ Worth investigating
- →No Scout cycle.completed for more than 6 hours — check if cron is running
- →Bridge calls with level: error — target agent may be down or unreachable
- →Recall queries returning result_count: 0 consistently — QMD may be empty or broken
- →monitoring.completed with alerts_detected > 0 — check which service triggered
- →Cost spike over 10× normal in one cycle — Codex may have looped
- →Multiple governance.redirect events in a row — Scout may be misaligned on scope
Investigating an Issue, Step by Step
Something looks wrong. Here's a structured approach:
Check Service Health first
If a service shows red, that's usually the root cause. Red Recall means knowledge queries failing everywhere. Red Bridge means agents can't talk. Fix infrastructure before investigating agent behavior.
Narrow the time window
Use the time filter in the Event Stream to focus on when things went wrong. If an agent's last cycle was at 3 PM and it's now 9 PM, look at the 3 PM window.
Filter by service
Pick the specific agent or service that seems affected. Look for the last successful event, then find where it stopped or started erroring. The gap tells you when the failure began.
Look for level: error events
Switch the level filter to "error only." Error events include a message or meta payload that usually explains what failed — timeout, HTTP error, missing file, parse failure.
Follow the Bridge log
If the issue is in agent coordination, find sessions around the failure time. Low turn count + short duration + error = the remote agent likely rejected or couldn't respond.
Cross-reference Monitor alerts
Find the nearest monitoring.completed event before and after the issue. If alerts_detected jumped from 0 to 1+, the monitor caught it. The meta.services field shows which service triggered the alert.
Status Indicator Reference
🔭 Planned Enhancements
These alerting capabilities are queued for Watchtower and will appear as new alert types once shipped.
Daily/weekly cost trend detection. When Codex API or delegation spend exceeds a rolling average by >2× (or crosses a configurable absolute daily ceiling), a cost_trend alert fires. Extends detectCostSpikes() from per-event to windowed aggregation.
Surfaces follow-up items from governance decisions or bridge conversations that were deferred. When an Atticus decision or bridge message includes "follow up" or "defer to next" with a time reference, a time-boxed reminder alert is created.
Detects when an agent that normally runs on a cron schedule has gone silent beyond its expected interval. Generates an agent_silent alert when the gap exceeds 2× the cron interval.