Digests & notifications

A digest is the periodic email summary of activity across your tracked sources. It rolls up new releases since the last digest, filtered by your notification threshold. Available upgrades aren't part of it: they live on each lockfile's page, where you pick them up when you're doing dependency work.

Configuring the digest #

From Settings → Digests:

• Frequency. Disabled, weekly, daily, monthly, or real-time. Weekly is the free tier's cadence; daily, monthly, and real-time are on paid plans. Turning the digest off is always available. What a paid plan buys here is control over when you are reached, never whether you are told: security alerts are sent immediately on every tier, including the free one (see which advisories interrupt the cadence).
• Send days. For the daily and real-time cadences you can restrict delivery to specific weekdays: for example, weekdays only, to keep weekends quiet. Activity on the days you switch off is not dropped: pending updates accumulate and roll into your next email on an enabled day, so a Monday send covers everything from the weekend. Weekly and monthly digests already target a single day you pick, so they ignore this setting.
• Time of day. Pick a delivery time in your local timezone; we store the timezone you select so DST shifts don't move your delivery slot unexpectedly. (The timezone also defines when a "day" starts for the send-days setting.)
• Day of the month. For the monthly cadence, pick any day from the 1st to the 28th. The list stops at the 28th so your digest exists in every month: a 30th or 31st anchor would silently skip February and, depending on the day, four other months a year.
• Threshold. The minimum risk score that earns a place in the email. Default is 70 (High band).

Which advisories interrupt the cadence #

A newly-disclosed security advisory against one of your pinned versions can be emailed immediately, outside the digest schedule. The security alert bar decides which ones qualify: pick the lowest severity that is worth interrupting you for, and anything at or above it arrives the day we detect it. Anything below the bar is not emailed as an alert: it is tracked in full on that lockfile's page and returned to your agents by the MCP tools. The digest is not a catch-all for those either; its Security Advisories section carries only critical and high-severity advisories that have no fix release yet (see what's in a typical digest).

The bar defaults to High and above, and you can set it to critical-only, medium and above, or low and above.

Alerts are never gated on your digest frequency. Moving to a monthly digest does not delay a critical advisory by a month; it still reaches you the day it lands. The only setting that stops alerts is Disabled, which turns off email entirely. That separation is what makes a low-frequency digest safe to choose.

Per-project bars #

Risk appetite belongs to the project, not the person. A client-facing payments service and a throwaway internal tool can sit in one account and deserve different answers, so each lockfile can set its own bar from its page. A lockfile left on Account default follows the setting in Settings → Digests, so you only override the projects that need it.

Two details worth knowing:

• Widening the bar applies going forward. Lowering it to catch more starts with the next advisories we detect, rather than replaying every historical one into your inbox at once. If a project is quiet, that can mean no new alerts until something actually changes; the issues themselves are already listed on the lockfile page, which is where to look right after widening.
• Narrowing the bar takes effect immediately, including for advisories detected but not yet emailed. Those are dropped rather than delayed, so narrowing and then widening again does not deliver what you skipped.

An alert never repeats for an advisory you have already been alerted about.

An advisory we could not grade is never used to interrupt you, at any bar. It is still recorded and still on your lockfile page; only the interrupt is withheld, because an ungraded advisory is not evidence of urgency.

This is the only immediate email we send about a lockfile. Newly-available upgrades never trigger one, not even the ones we rate high-risk: "high risk" on an upgrade means risky to adopt, which is a reason to plan, not a reason to interrupt you. They wait for you on the lockfile page. See Available upgrades → security issues for what's covered.

Disabling the digest entirely is fine; the pulse feed is the source of truth for activity, and the email is just a convenient summary.

What's in a typical digest #

The email is organized so the things that need a decision rise to the top and the routine noise stays out of the way. Each section below (after the overview and highlights) appears under its own headline in the email:

• Overview: a tight two-to-three-sentence summary that leads with the single most critical item, security advisories first. It's the at-a-glance read before you scroll.
• Key Highlights: a short, deduplicated list of the most important items, one line per source. When the digest carries both releases and standalone advisories, the panel splits into two labeled sub-sections: Security Advisories first, then Priority Releases below. Each is capped on its own, so neither kind pushes the other out of view. Within the releases sub-section, items are ordered by severity (security updates, then breaking changes, then lower-risk signals) so every breaking change is grouped together near the top rather than scattered through the list.
• Security Advisories: advisories affecting packages you depend on that have no fix release yet, most severe first. They lead the detailed sections (mirroring the Key Highlights order) because they're the items most likely to need action, and there are usually only a few of them, so they never sit underneath a long run of release cards. Each card says which of your repositories use the affected package (read from your connected lockfiles, one entry per repository however many lockfiles it has), and the section opens with how many repositories the advisories reach in total, so you can tell whose problem it is before you open anything. A manual upload has no repository to name, so it's counted as one instead. The advisory's Key Highlights line says the same thing in short: the repository when there's one, or how many when there are several. This section carries critical and high-severity advisories that have no fix release. Advisories against the versions you pin that clear your alert bar reach you as separate security alerts, and every lockfile's page carries its full security audit. When no new advisory of that kind has come in since your last digest, the section says so in one line rather than disappearing, so "nothing new" never looks like a missing section.
• Priority Releases: full cards for anything notable: security updates, breaking changes, or a Medium-or-higher risk score. When a single source ships several notable releases in the same window, they're grouped under one card (the source is named once) instead of repeating the header for each release. When the source's package is pinned in your connected lockfiles, the card names the repositories that use it, so you can see which projects a breaking change lands in. Sources you added by their GitHub repository rather than from a lockfile have no package name to look for, so their cards skip that line.
• Routine Updates: low-risk releases (dependency bumps, patch releases) are condensed to one line per source (the source name, a count, and a few version numbers) rather than a full card each. They're still in the email, just compact.
• Quick-actions: deep links into the relevant source detail, plus a "view all on your dashboard" link if the digest is long enough to be capped. If you're signed out when you click one, you're taken straight to that source after you sign in.

A release flagged with breaking changes is always treated as a priority release: it never lands in the condensed routine list and is never shown as "Low risk" (see risk scoring).

Keeping large digests readable #

If you track hundreds or thousands of sources, a digest that listed every release in full would be unusable. Three mechanisms keep it scannable regardless of account size:

• Routine low-risk updates are rolled up to a single line per source.
• The email caps how many full cards and routine lines it renders; anything beyond the cap is summarized in a single "+ N more updates across M sources, view all on your dashboard" line so nothing is silently dropped.
• The longer the cadence, the harder we summarize. See below.

Longer cadence, shorter email #

A monthly digest covers roughly thirty times the window of a daily one. If it used the same layout, the email would get longer the less often you asked for it, which is backwards: the person who chose monthly is the least likely to scroll a wall of releases.

So the density scales with the window:

Cadence	Full release cards	Routine updates
Real-time, daily	Up to 25	One line per source, up to 40 sources
Weekly	Up to 15	One line per source, up to 12 sources
Monthly	Up to 10	A single count, linking to the dashboard

Weekly and monthly digests also open with a counts row: security, breaking, notable, routine, and how many sources they came from. It answers "what happened while I was away" before you scroll, and it is computed over the whole window rather than over what survived the caps, so it never under-reports what the trimmed body leaves out.

Two things that deliberately do not change with cadence:

• What counts as notable. Security, breaking changes, or a Medium-or-higher risk score earn a full card at every cadence. A monthly digest is a shorter email about the same things, not a laxer one.
• Nothing is hidden, only counted. The monthly routine section reads "184 low-risk releases across 47 sources" with a link, rather than dropping them. Your pulse feed remains the complete record.

Anti-spam mechanics #

• We coalesce duplicate releases (same source, retag, same version) into a single line, and condense low-risk routine updates to one line per source.
• If nothing crossed your threshold during the digest window, no email is sent. Quiet inboxes when nothing's happening.
• Back-catalog isn't emailed as if it were new. When a source is first ingested (or when a parser that had been quiet catches up and imports a run of older releases at once), those already-dated releases don't flood your daily email. A release we only get to more than about a week after it was published is treated as history, not an update, so it's shown on your pulse feed (the source of truth for activity) without leading your inbox. Genuinely new releases (the normal case, where we pick up a release within a day of it landing) email as usual.
• Unsubscribes are honored at the SES level immediately; you can also toggle the digest off from settings.

Per-source overrides #

Digest frequency, send time, and risk threshold are configured at the account level; there's no per-source threshold. If a single source is generating noise, the better lever is to deactivate it (sources don't poll once deactivated, and re-activating preserves the history).

The one setting that is per-project is the security alert bar, which each lockfile can override; see per-project bars above.

News & discussions (Pulse only) #

The Pulse News & discussions section surfaces highly-engaged open GitHub issues on your tracked repos. These rows are not included in email digests today: issues are noisier than releases or advisories, and we'd rather you check them when you're already in the dashboard than send a longer email. Releases and advisories continue to drive the digest.