# Auditor response — 2026-04-25 — watcher health check at +19m

## Healthy

| Check | Result | Expected |
|---|---|---|
| Process | PID 3170546 alive, 18m49s elapsed, 97 MB RSS, status `Sl` (sleeping interruptible — normal) | Alive |
| Polls/min per venue | **60 ok / 0 err** for all 4 venues, every minute, last 18 minutes | 60/min (1 Hz) |
| Total errors since start | **0** across all 4 venues | 0 ideally |
| JSONL rows | 9,256 (≈ 9,120 expected for ~19 min × 8 rows/sec) | linear growth |
| Last 5 sec | 4 venues × 2 symbols × 5 sec = 40 rows captured cleanly | 40 rows |
| File size | 1.5 MB in 19 min ≈ 4.7 MB/h, projects to ~28 MB over 6h | well below disk concerns |

The dev's per-minute summary log line:

```
[summary 1m] kraken=60ok/0err  coinbase=60ok/0err  binance=60ok/0err  okx=60ok/0err
```

Every minute since start: perfect score.

## What would tell us something is broken (and what to do)

| Symptom | Means | Action |
|---|---|---|
| Per-minute `ok` drops below 50 for a venue | Rate-limited or network hiccup | Watcher self-recovers via exponential backoff. Check log; if persists 10+ min, that venue's window data will be sparse — note in analysis. |
| `err > 0` consistently for a venue | API change or outage | Likely parser fix needed. Stop watcher, ping auditor, inspect response. Other 3 venues still good. |
| RSS memory > 500 MB | Memory leak | Restart watcher (kill + nohup again). Existing JSONL rows preserved. |
| `ps -p 3170546` returns nothing | Process died | Check `tail /tmp/spread-watcher.log` for crash trace; restart. |
| JSONL line count flatlines for >2 min | Stuck/zombie | Same as above. |

## Auditor's monitoring plan

Three natural checkpoints (no continuous polling — that just adds noise):

1. **+1h** (~2026-04-25 19:50 Melb) — confirm clean run through one hour
2. **+3h** (~2026-04-25 21:50 Melb) — mid-run sanity
3. **At analysis time** — final sweep

Optional: a `loop` background check every 30 minutes that pings only on anomaly. Available on request.