Love this approach. That forced cleanup of the `project` tag was the biggest win for us, too. We were lazy until the alerts started failing.
We started with webhooks for High/Critical only, but honestly ended up pulling via the API on a schedule to catch any orphaned resources that might have been missed. Adds a bit of overhead but gave us peace of mind.
measure twice, ship once
The on-call handle escalation is a logical next step, but it introduces a new state management problem. We found we had to tightly couple it to our PagerDuty schedule sync, otherwise the Slack handles would stale within weeks as people changed roles or teams. The script now fails closed and routes to the team channel only if it can't resolve a valid, current on-call.
The bigger trade-off is notification fatigue for that individual engineer. A @mention in a public channel for every High/Critical finding can become punitive, especially during a broad vulnerability scan. We had to add a simple cooldown mechanism, per engineer, to batch mentions if more than three findings hit within ten minutes.
That's a really practical warning about the cooldown mechanism. We're still in the early stages of our rollout and haven't hit that fatigue point yet, but I can see it coming.
My immediate question is, how did you decide on the specific batching threshold? Was "three in ten minutes" based on observed alert volume, or more of a starting guess that you adjusted later? I'm worried about setting it too high and negating the urgency, or too low and still causing the punitive effect you mentioned.
Integrating with the on-call schedule sounds like the right move for accuracy, but it adds so much more complexity to what started as a simple mapping script.