Alert preferences and filtering
Alert preferences decide which changes generate noise and where they go. You manage them in the app on each dependency or provider subscription (exact placement: Alerts, Notifications, or a tab on the detail page—wording varies).
What you can tune (typical UI)
| Control | Effect |
|---|---|
| Scope | Whole dependency, a domain you’ve mapped, or a single endpoint / operation. |
| Minimum severity | Only safe, risky, or breaking and above (labels match what you see on change rows). |
| Breaking-only | Extra gate so only contract-breaking items notify. |
| Channels | Restrict to Slack, Teams, email, PagerDuty—or leave broad if your org wants every connected channel to be eligible. |
| Email list | Addresses for this rule (when email is enabled org-wide). |
| On/off | Disable a rule without deleting it. |
Tip: If channels is narrowed to e.g. only email, Slack won’t fire for that rule—even if Slack is connected org-wide.
Provider (library) subscriptions
Catalog subscriptions often have a similar alert preferences screen with extras like domain or spec filters so large vendors don’t overwhelm one channel.
Plan limits
Some channels (especially Slack) may require a paid plan. The UI usually shows an upgrade path when you hit a limit.
Try it
- Connect at least one channel under Settings → Integrations.
- On a test dependency, create a narrow rule: e.g. Breaking only + one channel.
- Confirm lower-severity items stay in the app or email only.
Developers: HTTP API
Preference CRUD uses:
GET/POST/PUT/DELETE /api/dependencies/:id/alert-preferences/...GET/POST/PUT/DELETE /api/provider-subscriptions/:id/alert-preferences/...
Example JSON bodies: see historical Core resources tables.