changedInput schema / properties / event_type / description
Previous value: -"One of eight: down (alert opened), recovery (alert cleared), fail (explicit failure ping), every-run (one notification per completed run, success or failure), success (fires only when a run completes successfully), started (fires when a run begins), blocked (an agent reported it is waiting on a human — fires immediately, the moment the ping arrives; this is separate from the 'blocked' INCIDENT that opens later only if the wait outlives blocked_timeout_s, see create_monitor/update_monitor), note (a free-form annotation ping — never itself opens or clears an incident). Prefer down/recovery/fail: they fire only on a state change. every-run, success, started, and note are not state changes and are bounded only by how often the monitor runs (or how often the agent chooses to send them), so they can be very chatty, and none of them is flap-damped. started is the chattiest of the bunch for CI-fed monitors: GitHub maps both the workflow_run 'requested' and 'in_progress' webhook events to a start signal, so a single CI run can emit more than one started event — this was observed in production, where a real run logged two starts seconds apart. every-run, success, started, and note share one separate per-channel rate cap (60/hour by default), so together they can no longer use up the budget that down/fail/recovery/blocked need — but a chatty route on any one of the four can silently suppress its own notifications, and its sibling informational types' notifications, once it exceeds that shared cap. blocked is deliberately NOT in that shared group even though it is agent-reported rather than system-derived: a blocked agent needs a human, so it draws on the protected down/fail/recovery budget instead, precisely so it cannot be starved by chatty every-run/success/started/note traffic. Route informational types to a low-stakes destination, not to the one that pages someone."New value: +"One of eight: down (alert opened), recovery (alert cleared), fail (explicit failure ping), every-run (one notification per completed run, success or failure), success (fires only when a run completes successfully), started (fires when a run begins), blocked (an agent reported it is waiting on a human; held 10 minutes and sent only if that run is still blocked then, at most once per blocked stretch of a run: a note, step, success, fail or cancel for the same run inside the 10 minutes cancels it, a title does not; a blocked ping sent without a run id belongs to no run, so any non-blocked ping on the monitor ends its stretch: a start, log, note, success, fail or cancel of any run, or a step of the monitor's current run (any step when no run is current); this is separate from the 'blocked' INCIDENT that opens later only if the wait outlives blocked_timeout_s, see create_monitor/update_monitor), note (a free-form annotation ping — never itself opens or clears an incident). Prefer down/recovery/fail: they fire only on a state change. every-run, success, started, and note are not state changes and are bounded only by how often the monitor runs (or how often the agent chooses to send them), so they can be very chatty, and none of them is flap-damped. started is the chattiest of the bunch for CI-fed monitors: GitHub maps both the workflow_run 'requested' and 'in_progress' webhook events to a start signal, so a single CI run can emit more than one started event — this was observed in production, where a real run logged two starts seconds apart. every-run, success, started, and note share one separate per-channel rate cap (60/hour by default), so together they can no longer use up the budget that down/fail/recovery/blocked need — but a chatty route on any one of the four can silently suppress its own notifications, and its sibling informational types' notifications, once it exceeds that shared cap. blocked is deliberately NOT in that shared group even though it is agent-reported rather than system-derived: a blocked agent needs a human, so it draws on the protected down/fail/recovery budget instead, precisely so it cannot be starved by chatty every-run/success/started/note traffic. Route informational types to a low-stakes destination, not to the one that pages someone."
