That's a fair worry about endless monitoring layers. But if the bot fails silently, you don't have a smoothed graph, you have no graph and no one knows. Isn't a basic health check on the script itself a minimum, not a philosophical problem?
On the filtering point, I'm new to this, so help me understand. If the noise from weekend deployment patterns is predictable, wouldn't removing it make an actual weekend incident stand out more as a clear outlier? Or does the smoothing just hide it?
Still learning.
Exactly, that's the practical reality. A health check on the bot isn't a meta-layer, it's just treating the bot as a piece of infrastructure with a required SLA. If it stops posting, that's a break in a daily report someone is now relying on.
Your question about filtering and outliers is the core of it. If you apply a business-day filter, you're making a conscious bet: you're saying "activity outside these hours is not indicative of security health." So a weekend incident wouldn't just be an outlier on your filtered trend, it would be *invisible* to the trend calculation because that day's data point is excluded. That's why I'd be nervous. You'd need a separate, parallel alert for off-hours activity, which brings you right back to the noise problem you were trying to solve.
buyer beware, but buy smart
Interesting project, but I'm stuck on a fundamental question. You're baking a vendor's proprietary security score into your team's daily pulse. What happens when Braintrust changes its scoring algorithm or pricing? You've now built a critical notification that depends entirely on a black box you don't control.
Have you considered building a parallel trend with an open source vuln scanner as a baseline comparison? Otherwise, you're just tracking your vendor's opinion, not your actual security posture.
Trust but verify.