Sudden bounce surge = list contamination. Cap sends until investigated.
At a glance
A real-time alert that fires when the trailing-24-hour bounce rate exceeds 2 standard deviations above the trailing-30-day baseline. Detects sudden list-contamination events: a bad import, a paid-acquisition burst that brought in fake addresses, a corporate-domain block, or a list-cleanup mistake. The point of this card is to cap further sends until the cause is diagnosed, every additional send while bounces are spiking compounds the reputation damage.
Calculation
Calculated automatically from your Klaviyo data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A fashion brand with a healthy 30-day bounce-rate baseline of 1.4% (standard deviation 0.3%). On 14 Mar 26 the merchant runs a Spring promotion that includes a list segment imported the day before from a paid lead-gen campaign. The day’s send pattern looks like this:- The alert fires immediately, not at end of day. Klaviyo’s data updates within 30-60 minutes of send completion; the alert evaluator runs every 5 minutes. By 14:30 the merchant has notification on the Nerve Centre feed showing “Bounce rate at 2.67%, 4.2σ above 30-day baseline”. This gives the merchant 90 minutes to cancel the planned 16:00 re-send before it compounds the damage.
- The alert correctly identifies the cause as the lead-gen segment, not the brand itself. The 09:00 and 11:00 sends to the existing list bounced at the normal 1.4%. The 14:00 send to the imported segment bounced at 9%. Imports without double opt-in or email verification are the most common cause of bounce spikes. The fix is to suppress the imported segment until it can be verified by an external service (NeverBounce, ZeroBounce, or BriteVerify).
- The 16:00 re-send is the dangerous one. Cancelling the 16:00 send would have avoided 1,520 of the 5,920 bounces. The merchant doesn’t have to act, but every send while the alert is firing is sending into a partially-poisoned list and adding bounce data to ISP reputation systems. The alert exists to give the merchant an “override or cancel” decision point.
- A 4.2σ event is well above the 2σ threshold and very unlikely to be a false positive. The probability of a 4σ deviation on a stable signal is roughly 0.006%, so when this fires it’s almost always real. False positives at this level usually indicate the baseline itself was wrong, the merchant had a bad campaign 30 days ago that’s deflating the recent baseline, making any normal send look like a spike. Watch for the alert firing twice within a week; if so, recalibrate the baseline window.
- The 30-day baseline is wider than it sounds. Each day’s bounce rate enters the baseline; a bad campaign from 25 days ago is still contributing. After a known list-cleanse event, the baseline mean drops and the standard deviation tightens, which makes the alert more sensitive (a good thing) for the next 30 days.
Sibling cards merchants should reference together
Bounce Spike is a real-time alert. Pair it with these:Reconciling against the vendor’s own dashboard
Where to look in Klaviyo: Klaviyo doesn’t expose a native bounce-spike alert. The closest views are:- Analytics → Deliverability, the 30-day bounce-rate line chart. Visual spikes are obvious but Klaviyo doesn’t proactively notify.
- Campaigns → individual campaign → Performance, per-campaign bounce rate. Useful for confirming which campaign caused the spike after the fact.
- Account Settings → Sender Reputation. Klaviyo’s blended reputation tile, which degrades when bounces spike but updates with 24-48 hour lag.
Cross-connector reconciliation:
This is a Klaviyo-internal alert. Cross-connector relevance is limited.
Known limitations / merchant FAQs
The alert fired but my bounce rate looks fine in Klaviyo’s dashboard, what’s going on? Klaviyo’s dashboard shows the 7-day or 30-day rolling rate, which absorbs a 24-hour spike. The alert is firing on the 24-hour rate compared against the 30-day baseline. Both can be true: a 2.5% blended 30-day rate (looks fine) with a 7% 24-hour rate (alert fires). Look at Klaviyo’s per-campaign view for the last 24 hours to see the offending send. What should I do when this alert fires? Five-step playbook: (1) identify the campaign that caused the spike, look at sends in the last 24 hours sorted by bounce rate descending; (2) suppress everyone who bounced in that send (Klaviyo auto-suppresses hard bounces, but soft-bounce suppression often needs manual segment work); (3) cancel any planned sends in the next 12-24 hours; (4) audit recent imports or paid-acquisition acquisitions for list source quality; (5) once the 24h rate falls back to within the baseline, resume sending to engaged segments only for 3-5 days before returning to full-list sends. How do I tune the alert threshold? The 2σ threshold is fixed for now. If the alert is creating noise (2-3 false positives per quarter on a healthy account is normal), the merchant should investigate the baseline period rather than raising the threshold. Most “false positives” turn out to be real, just smaller, list-degradation events. The baseline includes a bad campaign from 28 days ago, can I exclude it? Not currently. The alert evaluator uses a flat 30-day window. If the merchant had a known bad event in the baseline period, the alert is harder to trigger because the baseline mean and stddev are inflated. After the bad event ages out (30 days later), the alert becomes correctly sensitive again. Does this alert fire on flow bounces? This alert is keyed offcampaign-values-reports only, same as klv_bounce_rate. Flow bounces are not aggregated. For most accounts, campaigns are 80-90% of send volume, so a bounce spike in flows alone is rare and would not trigger this alert. A separate flow-bounce alert is on the roadmap.
My account is new (less than 30 days old), does the alert work?
Vortex IQ requires at least 14 days of baseline data before evaluating. New accounts will see the alert as “calibrating” for the first 2 weeks. After 14 days the alert evaluates against a partial baseline; after 30 days it stabilises.
Why is the alert lag 30-60 minutes? Why not real-time?
Two reasons: (a) Klaviyo’s bounce data is itself batched, ISPs report bounces back to Klaviyo with 5-30 minute delay, and Klaviyo aggregates those into the campaign report; (b) the alert evaluator polls every 5 minutes to keep API call volume sustainable. Reducing this lag below 15 minutes is non-trivial without dedicated webhook infrastructure, which is on the roadmap for high-volume accounts.
Does this alert pause my sends automatically?
No, this is a notification-only alert. The merchant decides whether to cap or proceed. Auto-pause is on the roadmap but is risky to ship as a default, for some merchants the alert is a known-acceptable spike (planned cleanup campaign) and auto-pause would be unwanted.
The alert text says “list contamination”, what if the cause is something else?
“List contamination” is the most common cause but not the only one. Other valid causes include: (a) a transient ISP throttling event (e.g. Yahoo blocked a sending IP for 30 minutes); (b) a misconfigured authentication record (DKIM/DMARC) that suddenly fails; (c) a recipient-side rule that mass-bounced previously-delivered mail. The alert text is shorthand. Investigate by looking at which addresses bounced, similar domains across the failures usually points to ISP-side issues; scattered domains points to list issues.