Waterfall Operations

Run health, per-parser task performance, page workload, and error trends

snapshot

Range

Waterfall runs per day

Stacked by outcome · line = average completed-run duration (right axis)

Run latency per day

Completed runs, submission to done · log scale · p50 = typical, p95 = tail

Task executions by parser

Executed = completed + failed · skips shown for context (waterfall didn't need the parser) · all columns follow the selected range; multi-day p50/p95 (marked ~) are completion-weighted averages of daily percentiles

Pages parsed per day

Which parser owned each page · the cost view: early parsers are cheaper

Task errors per day

Stacked by error type, all parsers

Error hotspots

Top parser × error type in this window

Methodology. Runs are waterfall_waterfallrun rows (one per file processed through the waterfall); "stuck retries" counts runs with stuck_retry_count > 0. Task executions are waterfall_waterfalltaskexecution rows; a parser's failure rate is failed ÷ (completed + failed) — skipped tasks (the waterfall didn't need that parser for the file) are excluded from rates but shown for context. Durations are for completed tasks. Pages come from waterfall_filepageparser: each row attributes one file page to the parser that owned it — the closest thing to a cost view, since earlier waterfall parsers are cheaper per page. Error types are the raw error_type values. Mock parsers excluded · Eastern-time days · weekends (Sat/Sun) excluded from every chart and metric · chart lines smoothed with a 3-day centered moving average at the 30d range (bars and tables stay raw) · inlined window is rolling 30 days, laminr-prod.