Per-event completion of one or more runs (every monitoring event sharing a correlation_id), each reduced to "how many events have reached a final outcome, and how many are still going". Unlike getMonitoringStatsV2, which counts rows, this groups erp_monitoring_v2 by event_id first: an event retried twice and then processed counts once, as a success.

Per event: it is settled once it has a success row, a terminal error row (a non-retryable failure, retries exhausted, or the dead-letter closure), or nothing but informational rows (deduplicated, skipped). A warning never settles an event on its own: mapping and relation caveats are written BEFORE the final stage's success row, and a retry marker (warning with will_retry: true) means the queue will deliver it again. Everything else is in flight. A settled event's outcome is its worst terminal row — error beats warning beats success.

For an ERP file import, an event the mapping split into several writes (one row writing a product and a price, say) settles only once every write has reported a final result, whatever those results were; until then it is in flight. A write lost without any result keeps its event in flight.

Batched so a history page costs one request: pass every run on the page. A run that has reported nothing yet comes back with seen: 0, never omitted.

The denominator is NOT here: the producer owns it. For an ERP file import it is ErpImportProgress.events_published; seen is how many of those have reported anything yet. Freshness is near-real-time (ClickHouse ingestion lag).