- Published
- Byline
- GoHighLevel Partners Editorial
- Filed under
- GoHighLevel Automation
The pacing comes from several independent places, each behaving differently when reached — and the difference between delayed and dropped is everything.
GoHighLevel workflow rate limits: what throttles a big send
A workflow that behaves perfectly for one contact can behave very differently for four thousand. Somewhere between those two numbers, something starts pacing the work — and the confusing part is that the pacing comes from several independent places, each with its own behaviour when reached. An agency debugging a slow send usually looks in one of them and concludes the platform is broken.
Published figures change, so the useful thing to carry is not a number but a model: which layers can throttle, how each behaves when it does, and how to build a workflow that degrades gracefully instead of failing loudly.
Four independent ceilings
| Layer | What it limits | Behaviour when reached |
|---|---|---|
| Platform execution | How many workflow actions run in a period | Queued and delayed rather than dropped |
| Messaging provider | Messages per second to the carrier | Paced, and sometimes rejected |
| Carrier or inbox provider | What the recipient network accepts | Filtering or silent non-delivery |
| External API | Calls to a third-party service per period | Errors, which the workflow may not retry |
The distinction that matters is between delayed and dropped. A platform queue means everything eventually runs; a rejected API call means that contact’s step did not happen and nothing will notice. Diagnose which layer you are hitting before changing anything, because the responses are opposite: for a queue you wait, for a rejection you retry.
Slow is not the same as throttled
Before assuming a limit, rule out the ordinary causes. A wait step nobody remembers adding, a condition that is evaluating false, why a workflow will not refire preventing contacts from entering a second time, or a trigger that simply matched fewer records than expected — these produce exactly the same symptom as throttling and are far more common.
The quickest test is a single contact. Run one through manually and time each step. If a single contact moves through instantly, the sequence is fine and the issue is volume; if it stalls at the same step, the step is the problem and nothing about rate limits applies.
Bulk enrolment is where limits become visible
Adding thousands of contacts to a workflow at once is the operation that finds every ceiling simultaneously. bulk workflow triggers is the mechanism, and the setting worth using is whatever paces the enrolment — a drip or batch option that adds contacts over hours rather than all at once.
Pace it even when you are under the limits. A message going to a whole list in one burst looks to receiving systems exactly like the sending pattern they are built to block, so a send that technically succeeds can still land in bulk folders. spf, dkim and sending reputation explains the machinery, and warming up a sending reputation is the version of this for a sending identity with no history.
Messaging has ceilings that have nothing to do with the platform
Text and chat channels are rate-limited by the carrier and the registration behind the number, not by the workflow engine. business messaging registration determines what throughput a number is allowed in the first place, what governs whether a text arrives covers what else decides whether a message arrives, and messaging limits on WhatsApp has its own separate windows and allowances.
quiet hours and local time interacts with all of this in a way people find surprising: if a large send is paced across hours and runs into a restricted window, the remainder may be held until the window opens, so a queue that looked stuck was correctly waiting. Check the clock before assuming a fault.
External calls are the ones that fail silently
A workflow step calling a third-party service is subject to that service’s limits, and a rejection there is usually not surfaced as an error the operator will see. The contact continues to the next step as though the call succeeded, which produces a subtly incomplete outcome that is very hard to spot later.
Where a step matters, do not rely on it having worked. Have the receiving system confirm back — a webhook payload is the mechanism — and record the confirmations somewhere you can count, which a log kept outside the platform covers. A count that does not match the number of contacts processed is the only reliable signal that calls were dropped.
Designing a workflow that degrades well
- Put the irreversible or externally visible steps early, while the run is freshest, rather than at the end of a long chain.
- Spread wait steps so a large cohort does not converge on the same minute — a fixed wait applied to a bulk enrolment recreates the burst you were avoiding.
- Avoid a step that calls an external service once per contact where one call per batch would do.
- Prefer manual actions inside a workflow for anything a person must confirm, so the queue is visible rather than buried.
- Enrol in batches and watch the first one complete before starting the second.
- Send to a clean list — keeping the contact database usable means fewer wasted sends against whatever ceiling applies.
Point two is the one people rediscover repeatedly. Enrolling four thousand contacts and giving them all a two-day wait means four thousand actions attempting to run at the same moment two days later, at which point the burst you carefully avoided at enrolment happens anyway.
What to do when you think you have hit a limit
Stop adding contacts before investigating; a queue you keep feeding never drains and the diagnosis gets harder. Then establish whether items are delayed or missing, by counting how many contacts completed against how many entered. Delayed means wait. Missing means find the step that dropped them.
sequence limits and the pause trap is worth reading alongside this, because sequence-level pausing produces a stall that looks identical to throttling and has a completely different cause. When you do contact support, the useful information is the count, the window and the specific step — not “the workflow is slow”, which describes every possible cause at once.
Frequently Asked Questions
Why is my workflow running slowly for a large list?
Several independent layers can pace it: platform execution, the messaging provider, the receiving carrier or inbox, and any external service a step calls. Establish which one before changing anything, because a queue means wait and a rejection means retry.
How do I tell throttling from an ordinary problem?
Run a single contact through manually and time each step. If one contact moves instantly, the sequence is fine and the issue is volume. If it stalls at the same step, that step is the problem and rate limits are irrelevant to it.
Are contacts dropped when a limit is reached?
It depends on the layer. Platform-level pacing normally queues work so everything eventually runs. A rejected external API call is different: the contact usually continues to the next step as though it succeeded, leaving a silently incomplete outcome.
Should I pace a bulk enrolment even if I am under the limits?
Yes. A message reaching an entire list in one burst looks to receiving systems exactly like the sending pattern they are built to filter, so a technically successful send can still land in bulk folders and damage your sending reputation.
Why did my paced send stall part way through?
Often because it ran into a restricted messaging window. If a send is spread over hours and reaches hours when messages may not be sent, the remainder is held until the window reopens. Check the clock and the local time zone before assuming a fault.
Why do all my contacts hit the next step at the same moment?
Because a fixed wait applied to a bulk enrolment converges: four thousand contacts given a two-day wait produce four thousand actions two days later. Spread the wait so the cohort does not recreate the burst you avoided at enrolment.
What information is useful when reporting a rate limit problem?
The count of contacts that entered against the count that completed, the time window, and the specific step where they stopped. Stop adding contacts first, because a queue you keep feeding never drains and makes the diagnosis considerably harder.
We build your GoHighLevel account for you
CRM, pipelines, funnels, SMS and automation — configured for your business, not left for you to figure out.
- Setup (one-time)$850
- Ongoing (per month)$38.80
No obligation quote · reply within 1 business day
This site is independently operated and is not officially affiliated with, endorsed by, or sponsored by HighLevel LLC. We do not receive referral commissions — this is our own flat-fee implementation service.