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.
| What it counts | The 24-hour rolling bounce rate compared against a 30-day baseline. Specifically: bounce_rate_24h > mean(bounce_rate_30d) + 2 × stddev(bounce_rate_30d). |
| API endpoint + statistics field | POST /api/campaign-values-reports with statistics: ["bounces", "recipients"] over rolling 24h vs rolling 30d windows. |
| Why 2σ specifically | A 2-sigma deviation has a ~5% probability of occurring randomly. Setting the threshold lower (1σ) creates noise; higher (3σ) misses real events. 2σ is a working balance: 2-3 false positives per quarter on a healthy account, but catches real list-contamination within the first send. |
| Hard vs soft bounces | Combined, same as klv_bounce_rate. Klaviyo’s 2024-10-15 API doesn’t break them out, so the alert can’t distinguish between “list got worse” (hard bounces) and “ISPs throttled” (soft bounces). Investigate per-campaign in the dashboard to identify which. |
| Attribution model | Not applicable. This is a deliverability alert, not a conversion metric. |
| Email vs SMS | Email-only. SMS bounce spikes are tracked separately by Klaviyo’s SMS deliverability monitoring. |
| Page cap | 50 campaigns per call. The alert window (24H) is short enough that very few accounts hit the cap; only accounts running 50+ campaigns inside a single 24-hour window. |
| MPP impact | None. Bounces are SMTP-layer; MPP is application-layer. |
| Lag from event to alert | Klaviyo’s bounce data updates within 30-60 minutes of a send. The alert evaluates on a 5-minute schedule. Total expected lag from “bad campaign sent” to “alert fires” is 35-65 minutes. |
| Currency / refund handling | Not applicable. |
| Time window | 24H (rolling, real-time evaluation) |
| Alert trigger | >2σ vs 30D baseline (drives sender-reputation incident on the Nerve Centre activity feed) |
| Roles | owner, marketing, engineering |
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:| Hour | Send batch | Recipients | Bounces | Bounce % |
|---|---|---|---|---|
| 09:00 | Engaged subscribers (clean) | 18,000 | 252 | 1.40% |
| 11:00 | Spring promo (full list) | 142,000 | 1,988 | 1.40% |
| 14:00 | Spring promo (lead-gen segment, new) | 24,000 | 2,160 | 9.00% |
| 16:00 | Re-send to non-openers (mixed) | 38,000 | 1,520 | 4.00% |
| 24h rolling total | 222,000 | 5,920 | 2.67% |
- 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:| Card | Why pair it with Bounce Spike |
|---|---|
| Klaviyo Bounce Rate | The 30-day rolling rate. The alert fires on 24h vs 30d; this card is the 30d trend that absorbs the spike afterwards. |
| Klaviyo Sender-Reputation Risk Alert | Composite alert: fires when bounce >5% OR spam >0.1%. The bounce-spike alert is more sensitive (catches deviation, not just absolute level); the reputation alert is the absolute-line backstop. Watch both. |
| Klaviyo Spam Rate | Bounce spikes that spread across multiple sends often turn into spam-rate spikes 3-5 days later. The bounce-spike alert is the early warning. |
| Klaviyo Suppressed Profiles | The expected aftermath: Klaviyo auto-suppresses hard-bouncing addresses, so this number jumps within 24-48 hours of the alert firing. Watch the suppressions card to see the cleanup happening. |
| Klaviyo Subscriber Growth Rate | If this alert fires after a paid-acquisition campaign or list import, growth rate also spiked. Correlation suggests bad list source. |
| Klaviyo Total Sends | The denominator. Verify the alert isn’t firing because send volume crashed (which makes a few bounces look like a high percentage). |
| Klaviyo Top Campaigns by Revenue | Identifies the specific campaign that fired during the spike window. Cross-reference to find the contaminated send. |
| Klaviyo Email-Attributed Revenue | Revenue follows reputation with a 1-3 week lag. A bounce spike today predicts a revenue dip later. |
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.
| Reason | Direction of divergence |
|---|---|
| Time-zone. Klaviyo’s dashboard buckets data into the merchant’s account timezone; Vortex IQ uses UTC for the rolling 24h window. Boundary days vary. | Alert may fire 1-12 hours before the merchant sees the spike in Klaviyo’s daily view. |
| Baseline window. Vortex IQ uses 30-day rolling; the merchant might be eyeballing 7-day or “this month” in Klaviyo. | Different baseline = different sense of “normal”. |
| Page caps. 50 campaigns per call. If a high-volume merchant ran >50 campaigns in 24h, the alert evaluator sees only the first 50. | Rare; affects only enterprise senders. |
| Standard-deviation calculation. Vortex IQ computes σ on the 30 daily bounce rates; the merchant might compute σ differently (per-campaign, weighted by sends). | Different math = different threshold. |
| Lag from send to data availability. Klaviyo’s API surfaces bounce data within 30-60 minutes; the alert evaluator runs every 5 minutes. Total lag 35-65 minutes. | Alert fires soon after the cause, but not instantly. |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
| Gmail Postmaster Tools (no connector) | Postmaster shows IP-level bounce data. A Klaviyo bounce spike should correspond to a Postmaster spike on the relevant Gmail-hosted IPs. | Postmaster updates daily, not in real-time. The Vortex IQ alert leads Postmaster by 24-48 hours. |
shopify.total_revenue | Bounce spikes today often predict revenue dips 1-3 weeks later if the spike persists. | Other channels can compensate. |
klv_alert_sender_reputation | The composite reputation alert often fires within 1-3 days of a bounce spike. | Reputation alert is broader, includes spam. |
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 sensitivity? 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.