Run totals per monitor across the project

The same runs GET /api/v1/runs lists, grouped by monitor instead of listed: how often each job ran inside a window, how often it succeeded, how often it failed, and how long it takes on average.

The outcome rule is the one rule. succeeded and failed here are computed by the same rule that decides outcome on GET /api/v1/runs — a terminal success/fail/cancel ping decides, an incident opened on a run with no terminal ping of its own means failed, a last-seen blocked ping means blocked, and anything else is still running or unfinished. So a success rate derived from these numbers can never contradict the list a reader has just filtered, and a cancelled, blocked, unfinished or in-flight run is counted in runs and in neither succeeded nor failed.

A run that exists only as spans is counted too, graded as Run.traced describes, and the set-up's test span is in no count.

?since= defaults to the last 30 days and is clamped to 365 days back, exactly as GET /api/v1/deliveries is. The response echoes the window it actually used in since, so a client labels the table from the answer rather than from its own request.

A monitor with no run inside the window is absent, not a row of zeroes. Read the absence as "this job did not run in this range".

There is no pagination: one row per monitor, bounded well above the per-project monitor limit.

Not mirrored in MCP or Terraform, and that is a decision rather than an omission: get_run_history already answers the same question for one monitor when an agent asks, and Terraform owns declarative configuration rather than rollups of what has happened.