Customer.io's Message Frequency Cap Now Works Channel by Channel. Nothing Is Capped Until You Say So

Radio has a number for how sick of a song you are. They call it burn, they collect it through callout research, and it comes back as the percentage of a listener sample who say they have heard a record enough. Ryan Research's guidance for Powergold, published on 9 January 2018, puts the old rule plainly: "Traditionally, once a song hit 20% Burn, it was deemed time to rest it." Heavy rotation gets you there sooner. Whirlwind rotations, the same piece warns, "will likely lead to a faster Burn".

The same piece calls the trade-off a dilemma over the "rotation of your best-testing songs": play them harder and more people hear their favourites, at the cost of burning all of them faster.

So the industry can measure fatigue, and it has a threshold. Acting on it is the harder part. Writing for Edison Research in September 2004, Sean Ross walked through station callout results with burn at 27%, 35%, 40% and around 50% on records still in rotation. At the same time, 11 of the 18 most-listened-to Top 40 stations were spinning their top song more than 80 times a week. Everyone could see the burn scores. The songs kept playing.

That is roughly where a lifecycle team stands the day a native frequency cap appears in workspace settings. Measuring the fatigue was never the hard bit.

On 20 July 2026 Customer.io made its message frequency limit channel-based. You can cap email, push, webhooks, SMS, WhatsApp and LINE separately, or pool them into one shared allowance, over a window of up to 31 days. This post covers what actually shipped, what the limit counts, the default that catches people out, and the channels it will never see.

Update (August 2026): this post originally said that only Twilio-routed SMS and WhatsApp could be counted, quoting the 20 July release note. That is no longer what the documentation says. As of the overview page's 17 August 2026 revision, limits apply to SMS through Twilio, Customer.io, Vonage, Infobip and Sinch, to WhatsApp through Meta as well as Twilio, and to LINE. The release note still carries the old sentence. The sections below have been corrected; the vendor exclusion is gone.

TL;DR:

• Customer.io's message frequency limit went channel-based on 20 July 2026. You can set per-channel limits, shared limits that several channels draw down together, or both in the same limit.
• The maximum time frame is 31 days, up from 7. The maximum retry window is 48 hours. They are different settings with different jobs.
• Twelve delivery paths can be capped. Three cannot: in-app messages, inbox messages and Slack.
• Nothing is capped until you say so. "By default, limits don't apply to any of your messages", and no workflow counts towards a limit until you assign it, workflow by workflow. This is the step teams skip.
• Limits are calculated per profile, not per campaign, on a rolling window measured from message delivery timestamps rather than calendar days.

What shipped on 20 July 2026

Customer.io's message frequency limit went from one blunt setting to a set of per-channel ones. This is an upgrade, not a debut. The release note is direct about it: "Historically, you could only set a single message limit across your message channels."

Three things changed.

Limits can now be per channel or shared. You can cap email at one number and push at another, or create a shared limit that several channels draw down together. Both shapes can live in the same limit.

The window stretched. "Instead of 7 days, your message limit can be up to 31 days," the release note says. A monthly contact cap is now expressible in the product rather than in a segment.

SMS and WhatsApp joined the list, and the vendor restriction has since lifted. At launch the release note was careful: "You can limit the number of WhatsApp and SMS messages sent via Twilio, but not other vendors." That clause decided whether the feature covered your SMS programme at all, and for ten days it did. It no longer holds. The overview page, updated 17 August 2026, shows every SMS vendor Customer.io supports as limitable, and the sentence excluding the others has been removed from the docs. The release note has not been updated, which is why this trips people up.

A message limit is not a rate limit

These two controls sound alike and measure opposite things. A message frequency limit is a cap on how many messages one person receives in a window. A send-rate limit is a cap on how fast one send leaves the building.

Customer.io documents rate limiting on one-time sends as a Limit send rate toggle: you set a batch size and a period, and the queue drains at that pace. It exists to protect your downstream systems and your sending reputation during a big broadcast, which is also why it pairs with Daily ramp for domain warming. Rate limiting is older than this release and has nothing to do with per-person fatigue.

Different axis, different job. A rate limit says "not this fast". A message limit says "not this person again".

Exactly what the limit can count

Twelve delivery paths can be capped and three cannot. The overview page sets them out in a table.

Channel	Sent through	Can limits apply?
Email	Customer.io	Yes
Email	Custom SMTP	Yes
Push notifications	Any	Yes
Webhooks (Send and receive data)	Any	Yes
SMS	Twilio	Yes
SMS	Customer.io	Yes
SMS	Vonage	Yes
SMS	Infobip	Yes
SMS	Sinch	Yes
WhatsApp	Twilio	Yes, but counts towards the SMS limit
WhatsApp	Meta/WhatsApp Business	Yes
LINE	Any	Yes
In-app	Any	No
Inbox messages	Any	No
Slack	Any	No

The page's prose says the same thing without the vendor rows: "You can apply your workspace's message limits to email, push notifications, LINE, webhooks, SMS and WhatsApp message channels."

One row needs reading twice. WhatsApp sent through Twilio does not get its own allowance: it "counts towards the SMS frequency limit". Customer.io explains why in a note on the same page. "If you integrated with Twilio before July 30, 2026, you can send both SMS and WhatsApp through Twilio," and in that case "the SMS message frequency limit applies to both SMS and WhatsApp, not just SMS." So an older Twilio workspace running both channels is drawing both from one pool, whether or not that was the intent. WhatsApp through Meta is counted separately. If you moved to native WhatsApp or LINE for an international audience, those sends are inside the cap.

For in-app and inbox, Customer.io points at different tools rather than the limit: expiration dates on both, plus page rules on in-app messages. They are real controls, but they cap the lifespan and placement of a message, not how many a person gets.

None of this overlaps with consent. Channel subscription preferences record what someone agreed to receive. A frequency limit governs how often you use permission you already have. Two layers, and a workspace needs both.

The default that catches people out

Creating a limit changes nothing on its own. The setup guide states it twice: "By default, limits don't apply to any of your messages" and "By default, no workflow counts towards a limit, and your messages inherit this setting from your workflow."

There is no out-of-the-box number and no default channel set. You build the limit, then you go and attach it, workflow by workflow... which is the step people skip.

Creating the limit:

1. Open Workspace Settings and select Message frequency limits.
2. Click Create limit.
3. Set limits per channel, or click Add a shared limit to pool several channels into one allowance. The maximum time frame is 31 days.
4. Optionally turn on a retry window. The maximum is 48 hours.
5. Click Create limit.

Then attach it. In an automation or an API-triggered broadcast, open Message settings and pick your limit under Message frequency limit. Individual message blocks have the same setting, so one email can follow a different limit from the rest of its automation, or ignore the workflow's setting altogether.

A naming note if your team is working from older documentation. Customer.io renamed Campaigns to Automations, People to Profiles and Newsletters to One-time sends on 15 July 2026, five days before this release. The message-limit pages use the new labels in their headings and steps, though a few worked examples still talk about campaigns.

Transactional and one-time sends, handled honestly

Transactional messages are not exempt. They are opt-in, through a switch of their own. Under Configure settings on a transactional message you enable the toggle Assign message frequency limit? and choose the limit. Nothing counts until you do.

One-time sends work the same way, via Sending options on step 1 once you have defined your recipients.

Both carry the same restriction: "Automatic retries do not apply to one-time sends or transactional messages." A blocked transactional message is marked Undeliverable and stays that way until a human resends it, which the docs describe as a manual retry from the message itself.

Customer.io's own worked example is the sane default. Set a limit for SMS marketing automations to stay compliant with state law, and leave it off transactional messages sending order confirmations, or a broadcast about a change to your terms. A password reset swallowed by a marketing cap is a support ticket, not a deliverability win.

How the count behaves per profile

The limit is calculated against the person, not the campaign. The docs are precise: "You assign message limits to workflows and messages, but we calculate message limits per profile."

That produces behaviour worth walking through, and the docs use a person called Sid. Campaign A has a limit of 2 emails per week. Campaign B has a limit of 5 emails per week. On Monday, both campaigns send Sid an email, so he has received two. On Tuesday, Campaign A tries again and is blocked, because Sid has already hit the number set on that limit. On Wednesday, Campaign B sends successfully, because Sid is nowhere near five. The email that filled up Campaign A's allowance came from a campaign with a different limit, and it counted anyway.

Two more mechanics matter.

Windows are relative, not calendar-based. Customer.io compares message delivery timestamps, down to the second. A limit of "2 emails per day" means two in any rolling 24 hours, not two between midnight and midnight. A slot reopens when the oldest counted message ages out.

Shared and individual limits stack. The docs give two combinations. A shared limit of 3 emails and SMS per week alongside an individual limit of 1 push per week gives a person no more than 4 messages in total. A shared limit of 3 emails and SMS per week alongside an individual limit of 1 email per week gives up to 3 messages, of which at most 1 is an email. That second shape is the useful one for an omnichannel contact strategy: a ceiling on total contact, with a tighter cap on your noisiest channel underneath it.

Retry windows, and what Attempted means

When a workflow tries to send to someone who has hit the limit, the delivery is recorded as Undeliverable straight away and the person carries on through the workflow. That is the behaviour with retries off.

Turn a retry window on and the sequence changes. The message is recorded as Attempted, the person waits at that step, and Customer.io retries when a slot opens up, which happens once the oldest counted message ages out of the window. If the retry window closes with the message still unsent, it flips to Undeliverable and the person moves on. The maximum window is 48 hours.

One sizing rule does most of the work: "For automatic retries to work reliably, set your retry window to at least as long as your message limit timeframe." The docs show why. Take a limit of 2 emails per 24 hours and a 12-hour retry window. A message blocked in the first 12 hours after the oldest counted email never gets a chance, because the limit cannot reset before the window shuts. Customer.io marks it Undeliverable immediately and stops.

Either make the window at least as long as the limit period or leave retries off. A 6-hour retry window on a weekly cap is decoration.

Four things to check once it is live

Deleting a limit un-caps everyone instantly. The docs spell out the consequence. Say someone has reached your limit of 2 emails per day and you delete that limit from workspace settings. "That profile can start receiving more than two emails that day" from the workflows that used it. There is no grace period, so deleting a limit at the wrong hour is a send-storm.

Retries outlive the automation they came from. With auto-retry on, "your workspace automatically retries messages that were blocked due to the message limit, even if a profile exited the automation the message came from." You cannot switch that behaviour off in isolation. Turning auto-retry off for that workflow or message is the only lever, which is a reason to think twice before enabling it on an automation with an aggressive exit condition.

Turning auto-retry off at the top does not reach custom windows. Disable auto-retry on a limit in workspace settings and it cascades to anything set to "Use message frequency limit settings". A workflow with its own explicit retry window keeps it.

Blocked messages are findable, but you have to read the reason. Undeliverable covers several situations, so filtering for it in Message activity is only step one. Expand the row and read the reason given for the capped delivery. The Usage section of your limit settings lists every automation, broadcast and transactional message observing that limit, which is the fastest audit of whether your opt-in pass actually covered everything.

Why a cap is worth the setup work

Frequency is the top reason people leave. Litmus from Validity surveyed 1,000 US consumers through Dynata in April 2025. It found that "the top reason consumers unsubscribe from a retailer's emails is that emails are sent too frequently (67%)". Inbox overload was also the primary reason people delete retail email unopened (39%).

ZeroBounce's 2026 report, updated in January 2026 from 1,091 respondents across four continents, lands in the same place. "For 43% of people, the primary reason they unsubscribe from an email list is that the sender emails them too often." Two surveys, two samples, one answer. That is the mechanism behind what an unsubscribe is really telling you.

It is a deliverability problem too. Google asks senders to "keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher", and one over-sent week can move that number. Which is why the 0.10% working ceiling belongs in the same conversation as your cap.

The playbook

Six moves, in order.

Pick a number from your own data. Start from what your best-retained cohort already receives in a month, not a round figure. The Litmus survey found most consumers prefer weekly email (32%) or two to three times a week (20%), which is a sanity check on your ceiling rather than a target.

Build a shared limit for total contact, then tighter per-channel caps underneath. Total contact is what a person experiences. Per-channel caps stop one noisy channel eating the whole allowance.

Opt every marketing automation in on purpose. Work through the list once, deliberately, then use the Usage panel to confirm the count matches what you expect. An unassigned always-on campaign is the exact hole this feature was meant to close.

Leave transactional out unless you have a specific reason. If you do cap it, remember there is no automatic retry, so someone has to watch for Undeliverable receipts.

Size the retry window to the limit period, or skip it. And keep it off where an aggressive exit condition means a retry could land after someone has already left the automation.

Keep hand-built suppression for the three channels the cap cannot see. In-app messages, inbox messages and Slack still need segment-based frequency logic. That is a much shorter list than it was at launch, and this release plus the August vendor change together retire most of the manual work described in our guide to suppression and frequency management. Check what you built by hand before you rely on it, and check again before you tear it out.

Treat the limit as one deliberate layer, and it earns its place. Treat it as a guarantee that nobody can be over-messaged and you will find the gaps the hard way. That means a month where someone gets eleven pushes, because nobody assigned the limit to the campaign sending them.

If you would rather someone else worked out the right numbers and audited every workflow against them, that is what our Customer.io consulting is for. Tell us what your programme sends today and we will tell you where the cap should sit.

Frequently asked questions

Does Customer.io have a native message frequency limit, and is it new?

Yes, and it is not new. Customer.io has had a message frequency limit for some time; what changed on 20 July 2026 is that it became channel-based. The release note states that "historically, you could only set a single message limit across your message channels". The news is per-channel and shared limits plus a longer window, not the arrival of capping itself.

Which channels can and cannot be capped by the message frequency limit?

Twelve delivery paths can be capped. Those are email through Customer.io, email through custom SMTP, push notifications, webhooks fired by the Send and receive data action, SMS through Twilio, Customer.io, Vonage, Infobip or Sinch, WhatsApp through Twilio or Meta/WhatsApp Business, and LINE. Three cannot: in-app messages, inbox messages and Slack. The one row to read twice is WhatsApp through Twilio, which draws down the SMS allowance rather than getting its own.

Do message frequency limits apply to SMS sent through Sinch, Infobip or Vonage?

Yes, according to the current documentation. The overview page, updated 17 August 2026, lists SMS through Twilio, Customer.io, Vonage, Infobip and Sinch as all supporting limits, and the set-up page lists SMS as a configurable channel with no vendor qualifier. The 20 July 2026 release note still says the opposite, that you can limit SMS "sent via Twilio, but not other vendors", and has not been updated. Verify it in your own workspace before you depend on it.

Are transactional messages exempt from the frequency limit?

No, but nothing counts until you opt in. On a transactional message you enable the toggle "Assign message frequency limit?" under Configure settings and choose the limit. Transactional messages cannot be retried automatically, so a blocked one stays Undeliverable until someone resends it by hand.

Are in-app and inbox messages included?

No. In-app and inbox messages sit outside this feature entirely and cannot be counted towards a limit. Customer.io suggests other controls for them: expiration dates on both channels, plus page rules on in-app messages. Neither is a per-person frequency cap, so cross-channel fatigue logic for those channels still has to be built with segments.

What is the difference between a message frequency limit and rate limiting in Customer.io?

A message frequency limit caps how many messages one person receives in a time window. A send-rate limit caps how quickly a single send leaves Customer.io, in batches over a period. One protects the recipient from fatigue, the other protects your downstream systems and your sending reputation during a large broadcast. They are independent settings and you can use both.

What is the maximum time frame, and the maximum retry window?

The maximum time frame for a message limit is 31 days, up from 7 days before the 20 July 2026 release. The maximum retry window is 48 hours. Both are set while you create the limit, but at different levels: the time frame belongs to each channel or shared allowance, while the retry window applies to the limit as a whole.

If someone hits the limit, what happens to the blocked message?

With retries off, the delivery is recorded as Undeliverable immediately and the person continues forward in the workflow. With a retry window on, it is recorded as Attempted first, the person waits at that step, and Customer.io retries when a slot opens up as the oldest counted message ages out. If the window closes with the message still unsent, it becomes Undeliverable.

Does a limit apply automatically once I create it?

No. The setup guide says "by default, limits don't apply to any of your messages" and "by default, no workflow counts towards a limit". After creating a limit you have to assign it to each automation, API-triggered broadcast, one-time send or transactional message you want it to govern. This is the single most common misreading of the feature.

Can I set a different limit on one message inside an automation?

Yes. Messages inherit the workflow's limit by default, and you can override that on any individual Email, SMS, Push notification or Send and receive data block through its Settings panel. A message can follow a different limit or ignore limits altogether, in which case it sends regardless of how many messages that person has already had.

How long should the retry window be?

At least as long as the limit's time frame. Customer.io's guidance is explicit: "for automatic retries to work reliably, set your retry window to at least as long as your message limit timeframe." With a limit of 2 emails per 24 hours and a 12-hour window, a message blocked early in the period is marked Undeliverable straight away, because the limit cannot reset before the window shuts.

What happens if I delete a message limit that workflows are using?

The cap disappears immediately for every workflow that used it. In the docs' own example, a profile who has already hit a limit of 2 emails per day "can start receiving more than two emails that day" once you delete it. Change the numbers on a limit instead of deleting it, unless you actively want the cap gone.

Can I see which workflows are counting towards a limit?

Yes. Automations, broadcasts and transactional messages that observe a limit are listed under Usage in that limit's settings, and hovering the count shows the workflow names. It is the quickest way to check that your opt-in pass covered everything you meant it to.

How do I find messages that were blocked by a limit?

Filter for the Undeliverable status in Message activity or inside a workflow's Sent tab, then expand a row and read the explanation, because Undeliverable covers several situations. You can manually retry both Undeliverable and Attempted messages.

Does a message limit replace suppression segments?

Not entirely. It replaces the hand-built counting logic for every channel it covers, which since the August 2026 vendor change is email, push, webhooks, SMS through any supported vendor, WhatsApp and LINE. You still handle in-app messages, inbox messages and Slack yourself, and the limit does nothing about consent, which is a separate layer. Frequency capping and suppression solve neighbouring problems, not the same one.

Sources

• Set up channel-based message limits. Customer.io Docs, released 20 July 2026.
• Message frequency limits: overview. Customer.io Docs, updated 17 August 2026.
• Set up message frequency limits. Customer.io Docs.
• Review and retry messages blocked by a message limit. Customer.io Docs, updated 20 July 2026.
• One-time sends. Customer.io Docs.
• Why Your Best Marketing Channel Is Driving Customers Away. Litmus, from Validity, 12 June 2025. Survey of 1,000 US consumers by Dynata, April 2025.
• Into the Inbox: Email Marketing Statistics for 2026. ZeroBounce, updated January 2026.
• Email sender guidelines. Google, Gmail Help.
• Callout Research Tips Part 3: It's Not About Burn, It's About Balance. Stephen Ryan of Ryan Research for Powergold, 9 January 2018.
• Why Callout Hits No Longer Have Legs. Sean Ross, Edison Research, 30 September 2004.