Alerts and digests
The point of this product is fewer emails, not more. Here is exactly what triggers one, and every dial you can turn.
What triggers an email
We ingest advisories every 10 minutes and match them against the versions in your manifest. Free and Pro apps are checked every 30 minutes; Team apps every 10 minutes. An email goes out when all of these are true:
- New information affects your app: a new advisory, higher severity, newly known exploitation, a new applicable fix, or a vulnerability returning after a verified version fix.
- Its severity is at or above your instant threshold, which defaults to
high. - The match is against a real version, not a name mentioned in a blog post.
- The component is not a dev-only dependency, or you turned dev alerts on.
- You have not snoozed or resolved that alert already.
Other permitted new information waits for your digest. Repeated uploads, unchanged open findings and source refreshes do not trigger another email.
Adding several apps
Eligible initial findings provide your first summary. A separate upload confirmation is sent only when there are no eligible findings to summarise. Each notification pass groups new security information across your apps into one email.
Multi-app emails show up to 20 apps and up to 3 advisories per app, with the most urgent first. Counts cover the full batch, and links take you to the remaining details. Your daily or weekly digest includes only updates that have not already been reserved for another email. With nothing new to report, no digest is sent.
Categories
| Category | What it means |
|---|---|
| vulnerability | A published advisory matches a reported version. This does not confirm exploitability. This is the one that can trigger an instant email. |
| news | A vendor post or advisory mentions something in your stack with no version match confirming you are affected. Always digest or weekly, never instant. |
| eol | A runtime you use (node, python, postgres and others) has reached, or is approaching, end of life. Counted separately from open alert counts everywhere they are shown. |
Severity
| Severity | What it means | Default handling |
|---|---|---|
| critical | Severe impact, such as remote code execution or authentication bypass. Known exploitation is tracked separately. | Instant email |
| high | Serious, exploitable without unusual conditions. Data exposure, privilege escalation. | Instant email |
| medium | Real but needs conditions you may not have. Often denial of service. | Daily digest |
| low | Minor, or needs local access. End-of-life warnings land here too. | Daily digest |
| unknown | No severity published yet. Common for advisories in their first hours. | Daily digest |
Severity comes from the advisory source, normalised onto one scale. Where a CVSS score exists we use it: 9.0 and above is critical, 7.0 to 8.9 high, 4.0 to 6.9 medium, below that low.
Critical or known exploitation only
Match confidence
| Confidence | What it means |
|---|---|
| exact | The advisory names your reported version; runtime use is unverified. This is the one that gets an instant email. |
| range | Your reported version falls inside an affected range. Treated the same as exact. An unresolved entry is the one exception. |
| name-only | A vendor post or news item mentions something in your stack with no version data. Sent as news, weekly, never as a claim that you are vulnerable. |
News items are labelled as news everywhere they appear. We will never tell you that you are vulnerable on the strength of a blog post that happened to mention Next.js.
What an alert email looks like
From VibeBeacon <alerts@vibebeacon.app>
To you@example.com
critical advisory in My Coffee Shop POS: next
A security advisory affects My Coffee Shop POS
Authorization Bypass in Next.js Middleware
next 15.1.0, fixed in 15.2.3
A request with a crafted header can skip checks that run in middleware, such as auth. The advisory says Vercel-hosted deployments are protected.
npm install next@15.2.3GHSA-f82v-jwr5-mffw
Review with your AI tool
The email ends with a prompt for your coding agent. It lists the advisory, the version you run and the target, and asks the agent to check the claims before changing anything.
Example email. The advisory is real (March 2025) and the app is made up. Later Next.js advisories need newer versions than 15.2.3, so check current fixes before you update. A version match does not prove your app is exploitable. Delivery time depends on source refresh, matching and email delivery.
The Dev tooling band
Dev-only dependencies are scanned by default and remain visible on the dashboard. Turn on dev dependencies in Alert settings to include them in notifications. Their unchanged counts never trigger an email.
Digests
- Daily. One email per day, sent at the hour you pick, and only if something happened.
- Weekly if that suits you better. Both are available on every app, free or paid.
- Off is a real option. Instant alerts keep working.
A digest covers new information, with permitted news capped at 10 items per app. Related articles remain weekly-only. A stack-health line can provide context, but unchanged findings or scores never trigger a digest. Apps someone else shares with you appear under their own “Shared with you” heading.
Mute an app or group
Open Alert settings, an app, or a group to choose New alerts, Critical or known exploitation only, Off, or Inherit settings. App settings override group settings; groups inherit your account setting. These are personal preferences, including on shared apps, and apply to email and connected alert channels. Monitoring continues. Changing groups or turning notifications back on does not email the old backlog.
Where alerts can go
Instant email on high and critical advisories is free on every plan. The Team plan adds Slack, Discord and signed webhook channels, set up under Settings, Alert channels, plus checks every 10 minutes instead of every 30. Nothing about email changes: the channels are somewhere else for the same alert to go, not a replacement for the email you already get. See pricing for what Team includes.
Snooze, acknowledge, resolve, or not applicable
Snooze
Hides it until a date you choose, then brings it back. For when the fix has to wait until next sprint.
Acknowledge
Says you have read it. It stays on the dashboard and stays out of the digest.
Resolve
Closes it. If a later manifest still shows the affected version, it reopens rather than staying quietly wrong.
Not applicable
A verdict, not a status change: you or your AI tool checked the advisory against how the app actually uses the package and it does not apply. Needs a reason of at least 10 characters, and is excluded from the fix plan and open counts until a fresh upload actually changes the reported version.
A new inventory can resolve an alert when its match no longer qualifies. Omission or reduced scan scope can also remove a match and must not be called a verified fix. Check changed IDs and reasons in the upload report; see scan results.
Turning the volume down
- Raise the instant threshold to critical, so only the worst wakes you.
- Set the digest to weekly, or off.
- Turn news items off entirely if vendor posts are not useful to you.
- Leave dev tooling alerts out of email and stack health, which is the default.
- Pause an app while you are not running it, rather than deleting it.
The severity threshold applies across your account in Settings. App and group controls let you inherit the parent policy, receive new alerts, limit alerts to critical severity or known exploitation, or turn notifications off.
Unsubscribing
Every email carries a one-click unsubscribe, in the footer and in the headers your mail client reads. Unsubscribing stops all alert email, including instant alerts, and the dashboard keeps working. Billing email is separate and cannot be turned off while you have a subscription. What we do with your address is on the privacy page.