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 now cap email, push, webhooks and Twilio-routed SMS and WhatsApp 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.

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.

Twilio-routed SMS and WhatsApp can be counted. The release note is careful here: "You can limit the number of WhatsApp and SMS messages sent via Twilio, but not other vendors." That single clause decides whether the feature covers your SMS programme at all, and it is the part most teams will get wrong.

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

Six delivery paths can be capped and nine cannot. The overview page sets them out in a table, and the vendor rows are where the surprises are.

Can be limited: email sent through Customer.io, email sent through custom SMTP, push notifications, webhooks fired by the Send and receive data action, SMS sent through Twilio, and WhatsApp sent through Twilio.

Cannot be limited: SMS sent through Customer.io, Vonage, Infobip or Sinch. WhatsApp sent through Meta/Facebook Business. In-app messages. Inbox messages. LINE. Slack.

Read that SMS list again. Twilio is the only vendor of the five whose messages count, and Customer.io's own managed SMS is on the wrong side of the line. The docs state it flatly: "You can't apply workspace message limits to SMS managed by Customer.io or WhatsApp managed by Meta/Facebook Business." If you moved to native WhatsApp or LINE for an international audience, those sends sit outside the cap entirely.

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 the reason for a capped delivery reads like "Sending delivery would exceed frequency cap." 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 channels the cap cannot see. In-app, inbox, LINE, Slack, Meta-routed WhatsApp and SMS through any vendor other than Twilio still need segment-based frequency logic. This release shrinks the manual work described in our guide to suppression and frequency management; it does not retire it.

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, in a month when someone gets eleven pushes and a WhatsApp.

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?

Limits apply to email through Customer.io, email through custom SMTP, push notifications, webhooks fired by the Send and receive data action, and SMS or WhatsApp routed through Twilio. They do not apply to SMS through Customer.io, Vonage, Infobip or Sinch, WhatsApp through Meta/Facebook Business, in-app messages, inbox messages, LINE, or Slack. The vendor split is the part that catches people: Twilio is the only SMS provider whose messages count.

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. A delivery stopped by a cap gives a reason along the lines of "Sending delivery would exceed frequency cap." 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 the channels it covers, which is most email, push, webhook and Twilio traffic. You still handle in-app, inbox, LINE, Slack, Meta-routed WhatsApp and SMS through any vendor other than Twilio 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 31 July 2026.
• Set up message frequency limits. Customer.io Docs, updated 20 July 2026.
• 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.