On this page
VGraple CRM sends every broadcast through an automatic pacer that stays below Meta's throughput ceiling and tracks your portfolio's rolling 24-hour messaging limit in real time, so a large campaign slows itself down or parks itself before Meta starts rejecting sends. Neither of these requires any setup; they run the same way on every campaign, on every plan.
Pacing and daily limit
- 1Check your daily headroom before a large
- 2Decide whether to auto-continue if the limit
- 3Send the campaign and let pacing run
- 4Watch the campaign detail page if a
- 5Check your quality rating if sending feels
Before you start
- No configuration is required; pacing and the daily limit budget are automatic defaults, not settings you turn on.
- Know your number's current quality rating (Green, Yellow or Red) in Settings, Channels, since it directly determines your effective sending rate.
- Understand that the daily limit applies to your whole business portfolio, not just the number sending this particular campaign, if you run more than one WhatsApp number under the same Meta business.
Steps
- Check your daily headroom before a large send. On the Review & Send step of any broadcast, look at the Daily limit left line. It shows the exact remaining headroom, for example "8,200 of 10,000," calculated from unique recipients your portfolio has actually started template conversations with in the trailing 24 hours.
Decide whether to auto-continue if the limit runs out mid-send. On the Schedule step, the checkbox "Continue tomorrow if the daily limit runs out" is on by default. Leave it on for most campaigns; the remaining recipients will be sent automatically once the rolling window reopens.
Send the campaign and let pacing run automatically. No action is needed here. The token-bucket pacer for your channel checks capacity before every batch and waits if needed, invisibly, whether the campaign is a broadcast, a sequence step, or a flow send.
Watch the campaign detail page if a park happens. If the daily budget runs out, the campaign's status changes and a message appears at the top of the detail page stating the reason and, when relevant, when it will resume. See broadcast paused reasons for the full list of what can trigger this.
Check your quality rating if sending feels slower than expected. Go to Settings, Channels, and check the WhatsApp number's quality rating. YELLOW or RED both reduce the pacer's ceiling automatically; there is no manual override to force a faster rate on a degraded number, because sending slower is what gives the rating a chance to recover.
What you will see
A large campaign on a healthy (GREEN) number sends at up to 50 messages a second; you will see the funnel on the detail page fill in quickly. On a YELLOW or RED number, the same campaign visibly takes longer, and if the daily portfolio budget runs out partway through, the campaign's status changes to Scheduled (if auto-continue is on, with a resume time shown) or the remaining recipients show as skipped_quota (if auto-continue is off).
How does the sending rate adapt to my number's condition?
Meta allows roughly 80 messages a second per number on the Cloud API, and answers error 130429 above that. VGraple CRM's default of 50/s stays comfortably under that ceiling so a short burst, for example a batch of retries, never trips a hard limit. The ceiling then adjusts to your number's real condition: a YELLOW quality rating halves it to 25/s, RED cuts it to 5/s, and a coexistence number (one you also use in the WhatsApp Business app on your phone) is capped at 4/s regardless of quality, since Meta's own ceiling for coexistence numbers is far lower than a Cloud API-only number's.
If Meta itself pushes back mid-send with a 130429 throughput error, the pacer halves its rate immediately for the rest of that campaign and does not automatically recover to full speed. Recovery is deliberate rather than automatic on purpose: a campaign that has already tripped the limit once finishing the rest of its run slower is what actually protects the number, rather than immediately testing the same ceiling again on the next batch.
Why is the daily limit shared across my whole portfolio?
Since a 2024 change to Meta's policy, the messaging-tier limit (from TIER_50's 50 unique recipients up to TIER_100K's 100,000) applies to your entire WhatsApp Business portfolio, meaning every phone number under the same Meta business shares one rolling 24-hour budget, not one limit per number. VGraple CRM counts unique contacts your portfolio has actually started template conversations with in the trailing 24 hours, live, across every channel that shares the portfolio, and checks the remaining headroom before letting a campaign continue.
This is why two campaigns from two different numbers under the same business can compete for the same daily budget, and why VGraple CRM's tracking is portfolio-wide by design rather than per number. Without this, a business running a big campaign on Number A could unknowingly starve Number B's smaller, time-sensitive send of headroom, and neither campaign's owner would understand why.
Settings and options
| Setting | What it does | Default |
|---|---|---|
| Sending rate (per number) | Messages per second the pacer allows | 50/s (GREEN), 25/s (YELLOW), 5/s (RED), 4/s (coexistence) |
| Daily portfolio budget | Unique recipients allowed per rolling 24 hours, shared across all numbers in the portfolio | Set by Meta's assigned messaging tier |
| Continue tomorrow if the daily limit runs out | Auto-resumes a parked campaign when the rolling window reopens | On |
| Throughput backoff (130429) | Halves the sending rate for the rest of the campaign's run when Meta signals too-fast sending | Automatic, no manual recovery |
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| Campaign is sending noticeably slower than expected | The number's quality rating is YELLOW or RED, halving or cutting the pacing rate | Check Settings, Channels for the current quality rating; sending slower is intentional and helps the rating recover |
| Campaign paused with "over your daily messaging limit" | The portfolio's rolling 24-hour budget ran out mid-send | If auto-continue is on, it resumes automatically at the stated time; otherwise resume it manually from the Broadcasts page once headroom returns |
| Remaining recipients show status skipped_quota instead of resuming | Auto-continue was turned off for this campaign | This is expected behavior for that setting; use Retry to attempt them again once headroom is available |
| Sending suddenly slowed mid-campaign with no quality change visible | Meta returned a 130429 throughput warning and the pacer halved its rate for the rest of the run | Expected and intentional; the rate does not recover automatically within the same campaign |
| Two campaigns on different numbers both seem limited by the same daily budget | Both numbers belong to the same Meta business portfolio, which shares one daily budget | Expected since 2024's Meta policy change; plan large sends across numbers with the shared budget in mind |
Does pacing apply to anything besides broadcasts?
Yes. The same token-bucket pacer, and the same daily portfolio budget tracking, sit underneath every template send path in the product, not only broadcasts. A sequence step, a chatbot flow sending a template, and an automation rule all pass through the identical pacing and budget checks a broadcast does, since the number itself does not know or care whether a message came from a bulk campaign or a single automated step, Meta's throughput ceiling and the daily recipient limit apply the same way regardless of source. This is why a large broadcast and a busy day of sequence-driven messages compete for the same daily headroom, and why protecting the number requires this logic to live in one shared place rather than being reimplemented separately for each feature that can send a template.
Related reading
See every reason a broadcast can pause itself for the full list beyond pacing and the daily limit, and understanding and recovering your phone number quality rating for how the rating that drives pacing is calculated.