What triggers a notification
Findings at or above REEF_NOTIFY_MIN_SEVERITY (default high) raise a
notification.
Where they show up
- The bell badge in the dashboard header
/notifications/— the full feed (?unread=1for unread only)- An email copy — console backend in dev (
DJANGO_EMAIL_BACKEND), so in local development you’ll find it in thewebcontainer logs
A noisy scan can’t flood your inbox
dispatch.after_scan collapses a burst of more than 25 significant findings
from a single scan into one digest alert instead of one notification per
finding. A Grype scan against a stale host image, for instance, won’t page you
25 times in a row.
Read state
Notifications are either broadcast (everyone sees it) or per-user, with
per-user read state tracked separately (NotificationRead). Resolving or
suppressing a finding automatically marks its related notification read,
clearing the bell badge for it.
Endpoints
| Route | Purpose |
|---|---|
GET /api/notifications/ |
the feed (?unread=1 for unread only) |
GET /api/notifications/unread-count/ |
badge count |
POST /api/notifications/<id>/read/ |
mark one read |
POST /api/notifications/read-all/ |
mark all read |
Current limitation
Notification rules are hardcoded in app/notifications/dispatch.py — there’s
no in-UI rule editor yet. User-configurable rules are on the
Roadmap.