A Customer.io Rate Limit Walks People Past Messages It Never Sent. The Fix Is a Checkbox With a 24-Hour Fuse

In 1963, on Chicago's Eisenhower Expressway, a police officer stood on an entrance ramp and stopped traffic. He released cars one at a time, at a rate set by a pilot detection programme. It was the first ramp meter anywhere, and it looked like a downgrade: drivers who could previously join the motorway at will now had to queue on the slip road.

It worked. Holding cars back at the ramp kept the mainline below the density at which traffic collapses, so the road moved more vehicles per hour, not fewer. Los Angeles followed in 1968, and the FHWA's own benefits table later credited metering with a 25% increase in peak-period volume in Minneapolis and a 74% increase in Seattle. The engineering insight is one sentence long: a queue you hold is throughput, a queue you discard is loss.

Customer.io shipped ramp metering for your automations on 6 August 2026. The default setting discards the queue.

TL;DR:

• A Customer.io rate limit controls how fast one automation sends email, SMS, push and webhooks, from 1 to 60,000 messages per minute per channel. It is a per-automation setting, not a workspace cap, and it is not a frequency cap.
• By default, a message the rate limit stops is simply not sent, and the profile moves on: "If a message isn't sent due to a rate limit, people still continue forward in your workflow."
• The fix is Wait before continuing journey, set per message. It is not a guarantee: "If 24 hours pass, the profile continues on its journey."
• So the wait protects at most 1,440 messages for every 1 per minute you allow. Below roughly 35 messages a minute, a 50,000-profile send outlives the wait and people start walking past unsent messages anyway.
• Tick the box on any message a later step reads. Leave it off for standalone nudges. And set the number from your audience size, not from a round figure that feels safe.

A rate limit controls sending speed, not fatigue

Rate limiting caps the sending speed of a single automation. Customer.io's automation concepts and settings page puts it plainly: "Rate limiting lets you control how fast a single automation sends email, SMS, push, and/or webhooks. This is a per-automation setting, not a workspace cap."

You set it inside the workflow, not in workspace settings. Open the automation, click > Message settings, and set a limit for each channel between 1 and 60,000 messages per minute. (If the word automation still reads as campaign to you, Customer.io renamed the object—we covered what changed and what didn't.)

The release note gives two reasons to use it: "to protect your email sender reputation or to prevent overwhelming your downstream systems". Both are real. A sudden volume spike from a cold or half-warmed domain is one of the faster ways to earn a reputation problem. It is why Customer.io built a daily ramp for domain warming. It is also why bursts are dangerous: Google asks bulk senders to "keep spam rates reported in Postmaster Tools below 0.10%", a ceiling we broke down for Customer.io senders specifically. A webhook action that fires 20,000 times a minute at an API built for 200 is the other half of the problem.

What a rate limit does not do is protect the recipient. That is a different feature with a different scope. The docs draw the line themselves: "While a rate limit determines how fast a single automation can send messages, a message frequency limit determines how often your workspace can send messages to a single profile." If your concern is fatigue rather than throughput, you want channel-based message limits, or the wider suppression and frequency playbook.

The two features also cover different channels, and the gaps matter.

Channel	Rate limit?	Message frequency limit?	Recorded when a cap blocks the send
Email	Yes	Yes	Frequency limit: Undeliverable. Rate limit: no documented status
SMS	Yes	Yes	Frequency limit: Undeliverable. Rate limit: no documented status
Push	Yes	Yes	Frequency limit: Undeliverable. Rate limit: no documented status
Webhooks	Yes	Yes	Frequency limit: Undeliverable. Rate limit: no documented status
WhatsApp	No—unless sent via Twilio, where the SMS limit applies to both	Yes	Frequency limit: Undeliverable
LINE	No	Yes	Frequency limit: Undeliverable
In-app	No	No	Neither cap applies
Slack	No	No	Neither cap applies

Sources: automation concepts and settings for the rate-limit column, message frequency limits for the rest. The Twilio carve-out is worth reading twice: "if you send both SMS and WhatsApp through Twilio, then the rate limit for SMS applies to both message channels". Set a cautious SMS limit and you have silently throttled WhatsApp too. And if you have moved off Twilio to another SMS provider, that coupling disappears without anyone telling you.

The default advances people past messages that were never attempted

Here is the sentence the release note left out, from the docs page it links to: "If a message isn't sent due to a rate limit, people still continue forward in your workflow."

Read it as an engineer would. The rate limit does not queue the profile. It does not retry them later. It drops the send and moves the profile to the next node, on time, as though the message had gone out.

Compare the frequency-limit path, which handles the same situation with a paper trail. When someone hits a message limit, the workflow "records the message as Undeliverable, unless you enabled a retry window". With a retry window on, Customer.io logs the message as Attempted and keeps trying for up to 48 hours before giving up. The profile still continues forward, but you get a status, a count, and something to filter on.

The rate-limit path has no equivalent. Customer.io's automation and broadcast metrics documentation defines Sent, Delivered, Opened, Clicked, Converted, Unsubscribed, Failed, Bounced, Suppressed and Marked as spam. Failed is defined narrowly: "A failed message never made it to the delivery provider". That is an attempt that broke, not one that was never made, and no documented status covers a message a rate limit stopped before it was tried. If you want to know what your own workspace shows, send a small test through a deliberately tight limit and look; do not assume a report will tell you.

That is what makes this different from every other reason a message doesn't go out. An unsubscribe, a bounce, a suppression, a frequency cap: each leaves a mark. A rate-limited skip leaves the journey looking healthy.

Wait before continuing journey is a fuse, not a guarantee

Customer.io shipped the fix alongside the feature. From the release note: "To account for rate limits, you can now enable Wait before continuing journey for any message to make sure people receive your messages before moving forward in your automation."

You turn it on per message, not per automation. Click the message block or the Send and receive data (webhook) block, open Settings, and switch on Wait before continuing journey. The journeys documentation describes the behaviour: "If you want profiles to wait in an automation until a message or webhook is sent or all retries are exhausted, then adjust the action's settings."

Then comes the part nobody quotes: "This setting does not hold people indefinitely in your workflow. If 24 hours pass, the profile continues on its journey."

So the checkbox does not close the hole. It narrows it to 24 hours, and hands the rest of the job to the number you typed into the rate limit. The arithmetic is unforgiving and it is the same every time: a rate limit of n messages per minute clears at most 1,440 × n messages before the wait expires. At 1 per minute—the documented floor—that is 1,440 messages. At 500 per minute it is 720,000.

Modelled throughput from Customer.io's documented 1–60,000 messages-per-minute range, against the documented 24-hour ceiling on the wait setting. Not a measurement of any workspace.

Rate limit (messages/min)	Time to send 50,000 messages	Inside the 24-hour wait?
60,000	50 seconds	Yes
5,000	10 minutes	Yes
500	1 hour 40 minutes	Yes
50	16 hours 40 minutes	Yes
35	23 hours 49 minutes	Only just
10	3 days 11 hours	No
1	34 days 17 hours	No

Two things follow. First, the tight limits people reach for when they are nervous—1, 5, 10 a minute—are the ones most likely to blow through the wait on any audience worth automating for. Second, if your automation is triggered by a segment that adds thousands of profiles at once, the queue is the whole segment, not the trickle you pictured.

Tick the box only where something downstream reads the message

Per message, not per automation. The test is whether anything downstream reads that message.

Tick it when:

• A later branch depends on the send. Any condition of the form "opened", "clicked", "did not respond within three days" is a lie if the message never went out. The profile lands in the not-engaged branch by default.
• The message triggers another automation. If you have split a long workflow into smaller workflows linked by a send event, a skipped send breaks the chain and the reader never enters part two.
• A goal or exit condition hangs off it. Skipped sends quietly deflate conversion rates, because the denominator lost a message that was never counted. While you are in there, an exit-condition audit is worth the half hour.
• The message carries something the customer needs—a code, a confirmation, an expiring offer, a shipping update.

Leave it off when:

• The message is a standalone nudge and nothing reads it.
• The automation is genuinely time-sensitive in the other direction. Holding an abandoned-cart email for hours to guarantee delivery can be worse than dropping it.
• You are rate limiting webhooks purely to be polite to a downstream API that you know retries on its own.

The honest caveat: turning the wait on for every message in a rate-limited automation makes the whole workflow move at the speed of its slowest channel, and delivery windows stretch. That is the trade. Buy the guarantee where a later step needs it, not everywhere.

Set the number from your audience, not from a figure that feels safe

Start from the queue, not from a round figure. Divide the biggest audience the automation can enqueue at once by 1,440 to get the floor that keeps the send inside the wait window—50,000 profiles needs 35 a minute, 500,000 needs 348. Then set the limit as high as your sender reputation and your downstream systems will take, and only lower it if there is a specific pressure you are managing.

For domain warming, the daily ramp is the right tool and a rate limit is a blunt substitute. For a webhook, take the documented rate of the receiving API and set the limit under it. For email on a mature domain, a rate limit is usually a safety net rather than a schedule.

This is the sort of thing that only bites at scale. When we consolidated Kip's two Customer.io workspaces into one, we merged 200,000+ profiles and 80+ live campaigns with zero disruption. A workspace that size is exactly where someone eventually sets a protective rate limit on a big re-engagement send. On the reporting side, our migration work with AIRE Health took campaign conversion from 7.0% to 17.8%, and a good part of that job was making the numbers mean something. A skipped-message default that leaves no status is the enemy of both.

If you would rather have someone audit your automations for this than do it yourself, that is what our Customer.io team does.

The audit worth running before your next big send

1. List every automation with a rate limit set. They are per automation, so there is no single settings page to check.
2. In each one, find the messages that something downstream reads: branches on engagement, send-event triggers, goals, exit conditions.
3. Turn on Wait before continuing journey for those messages.
4. Divide the largest possible enqueued audience by 1,440. If the rate limit is below that number, raise it or accept that people will walk past unsent messages after 24 hours.
5. Check the Twilio coupling. If SMS and WhatsApp both run through Twilio, your SMS limit is governing both.
6. Send a test through a deliberately tight limit and look at what the metrics actually show. Then you know, rather than assume.

If that audit turns up more than you want to unpick on a Friday afternoon, tell us what you're running and we'll go through it with you.

Frequently asked questions

Does a Customer.io rate limit skip messages?

Yes, by default. The documentation states: "If a message isn't sent due to a rate limit, people still continue forward in your workflow." The message is not queued for later and not retried—the profile advances to the next step in the workflow as though it had been sent. Enabling Wait before continuing journey on that message changes the behaviour for up to 24 hours.

Is a rate limit the same as a frequency cap in Customer.io?

No. Customer.io's docs separate them: a rate limit "determines how fast a single automation can send messages", while a message frequency limit "determines how often your workspace can send messages to a single profile". A rate limit protects your sender reputation and your downstream systems. A frequency limit protects the recipient from being messaged too often.

Is the rate limit per automation or per workspace?

Per automation. The docs are explicit: "This is a per-automation setting, not a workspace cap." You set it inside the workflow by clicking > Message settings, and each channel gets its own limit. Message frequency limits, by contrast, are set at the workspace level.

What is the maximum rate limit in Customer.io?

You can set between 1 and 60,000 messages per minute for each channel. The floor of 1 per minute is a genuine setting, and it is slow enough that any sizeable audience will outlive the 24-hour wait window.

Can I rate limit WhatsApp, in-app, LINE or Slack messages?

No. The docs say: "you can't set a rate limit for WhatsApp, in-app, LINE, or Slack messages". There is one indirect exception: "if you send both SMS and WhatsApp through Twilio, then the rate limit for SMS applies to both message channels". So WhatsApp sent through Twilio inherits your SMS limit whether you intended that or not.

What does Wait before continuing journey actually do?

It holds a profile at a message or webhook block until the action sends or all retries are exhausted, instead of letting them continue immediately. You enable it per message, in the block's Settings. It applies to message blocks and to Send and receive data (webhook) blocks, and Customer.io recommends it specifically for rate-limited automations.

What happens when the 24 hours run out?

The profile carries on without the message. The documentation is direct about it: "This setting does not hold people indefinitely in your workflow. If 24 hours pass, the profile continues on its journey." That is why the rate-limit number matters as much as the checkbox—if the queue cannot drain in a day, the wait expires and you are back to the default behaviour.

Will a skipped message show as failed in my reporting?

The documentation does not say it will. Customer.io's metrics documentation defines Failed as a message that "never made it to the delivery provider". That describes an attempt that broke, and no documented status covers a message a rate limit stopped before it was tried. Test it in your own workspace with a deliberately tight limit before you build a report on the assumption either way.

Does Wait before continuing journey delay everyone or only the people whose message was skipped?

It applies to the message block, so every profile reaching that block waits until their own message sends or its retries are exhausted. How that plays out depends on how fast your queue drains, which the docs do not describe. Send a small test through a tight limit and watch it before you rely on the behaviour.

Does the rate limit apply to API-triggered broadcasts?

The release note says it does: "You can now add a rate limit per channel for each of your automations and API-triggered broadcasts." The automation settings page describes rate limiting only as a per-automation setting, and the API-triggered broadcasts page does not mention it. The separate published limits there are unrelated: you cannot trigger a broadcast more than once every 10 seconds, and you cannot have more than five queued for the same broadcast.

Should I rate limit a domain warm-up send?

Use the daily ramp for warming instead. It is built for the job and steps volume up over days. A rate limit works minute by minute and has no notion of days at all, which is what makes it a blunt substitute for warming. A rate limit is a reasonable second layer once the ramp is doing the main work.

Do rate limits improve deliverability?

Indirectly, and only for a specific failure. Spreading a large send protects against the volume spikes that damage sender reputation, which is one of the two reasons Customer.io gives for the feature. It does nothing for authentication, list quality or content, which are the things that decide most inbox placement.

Where do I find the rate limit setting?

Inside the automation's workflow, click > Message settings. The rate limit is set there, per channel, alongside the automation's subscription preferences and message frequency limit settings. It is not in workspace settings, so auditing means opening each automation.

Sources

• Customer.io, "Control how fast your automations send messages", release notes, 6 August 2026.
• Customer.io, Automation concepts & settings, updated 20 August 2026.
• Customer.io, Pause journeys if they haven't received a message, updated 20 August 2026.
• Customer.io, Message frequency limits, updated 20 August 2026.
• Customer.io, Automation and broadcast metrics, updated 15 July 2026.
• Customer.io, API-triggered broadcasts, updated 20 August 2026.
• Google, Email sender guidelines, Gmail Help.
• Federal Highway Administration, Ramp metering, Office of Operations; benefits table sourced to the FHWA Ramp Management and Control Handbook, 2006.
• Gary Piotrowicz and James Robinson, Ramp Metering Status in North America—1995 Update, Federal Highway Administration and Federal Transit Administration, June 1995.
• Gary Richards, "The man who invented metering lights", East Bay Times, 3 August 2018.