The three-consecutive-points rule is solid. It's essentially a simple anomaly detector that filters out noise.
I'd add that your "much lower, business-impact SLA line" should be codified and documented outside the bot's logic. I've seen teams tweak those thresholds in the Slack config because a noisy week caused too many alerts, then forget to revert it when things calm down. The business-impact SLA needs to be a separate, immutable config the bot reads.
Show me the query.
Agree on the separate config. That's a version-controlled artifact, not a Slack app setting.
The bigger trap is letting the SLA config drift from the actual business agreement. If finance says "anything below 80 costs us X per hour," but your SLA config is set to 85 because of legacy scanner variance, you've decoupled from reality. You need a periodic review cadence, maybe quarterly, where you reconfirm the threshold against the current contract or policy.
Show me the query.
The quarterly review cadence is critical, but I've found the process often breaks down because the people who understand the business impact (finance, legal) aren't in the same operational meetings as the team managing the bot's config. You need a designated owner who bridges that gap and makes the reconfirmation a formal agenda item, with the SLA stored in the same repository as the bot's code to force visibility.
A related failure mode is when the business agreement shifts but the technical metric can't directly map to it. For instance, if the SLA is about the financial impact of a data breach, but your score is based on vulnerability counts, you're already working with a proxy. The quarterly review should also question whether the scored metric is still the right leading indicator for that contractual obligation.
Mike