Tune severity & noise
minSeverity tuning is the single biggest determinant of long-term value from Intello. With appropriate routing, the product fades into the background and surfaces only what your team needs to act on. Without it, alert fatigue sets in quickly and important changes get missed.
The principle
Page on Breaking. Notify on Risky. Surface Safe additions in the inbox and digests rather than in real-time channels.
The remainder of this page explains how to apply this principle in Intello.
Why a single channel for everything fails
When an integration is first added, every change is routed to the same channel. Within a week or two, breaking-change alerts begin to be lost in a stream of safe additions. Teams typically respond by muting the channel, at which point they have lost coverage entirely.
Severity routing separates "wake the on-call engineer" from "review on Friday."
Configuring per-dependency alert preferences
Alert preferences are configured per dependency. Open the integration at Dependencies → [integration] → Edit and locate the Alert preferences panel. For each preference rule you create, you can specify:
- Minimum severity — the lowest severity that triggers the rule (
safe,risky, orbreaking). - Channels — the destinations the rule activates (Slack, email, PagerDuty). An empty selection permits all configured channels.
A common starting configuration:
| Severity | Slack | PagerDuty | Email digest |
|---|---|---|---|
| Breaking | Yes | Yes | Yes |
| Risky | Yes | No | Yes |
| Safe | No | No | Yes |
This routes breaking changes to a human in real time, surfaces risky changes where work happens, and retains safe additions in periodic digests.
When to override per integration
Some integrations warrant different rules. A payments API may justify escalated routing; a low-criticality analytics provider may justify relaxed routing. Because preferences are already per-dependency, simply create rules with different thresholds on each integration. There is no global preference — every rule is scoped to a specific dependency.
What is classified as breaking
Intello classifies a change as Breaking when it would prevent code that worked previously from continuing to work. Specifically:
- An endpoint or operation is removed.
- A request field is added with a required constraint, causing existing callers to fail validation.
- A response field is removed that callers may rely on.
- A type is narrowed in a way that previously valid payloads no longer satisfy.
- An authentication requirement is tightened — for example, a new required scope.
If the provider versions the change away (for example, by introducing it in /v3 while leaving /v2 unchanged), Intello attaches the classification to the new version only.