On this page
A broadcast that looks stuck in Sending almost always has a real, visible reason on the campaign itself, pacing, a pause condition, or a worker temporarily unavailable, rather than being genuinely frozen. Knowing where to look first tells you within seconds whether to wait, act, or contact support.
Symptom
A campaign's status reads Sending, but the count of delivered or attempted recipients has stopped increasing, or is increasing much more slowly than expected for the campaign's size. Recipients further down the list still show Pending. There is no error shown to the person viewing the campaign at first glance, which is what makes this symptom disorienting: nothing visibly failed, sending simply appears to have stalled.
Why it happens
The first and most common explanation is not a bug at all: pacing. Every send passes through a token-bucket pacer that deliberately sends below Meta's throughput ceiling, 50 messages a second by default, and this rate drops automatically if the number's quality rating is YELLOW (25/s) or RED (5/s), or if Meta has returned a throughput error mid-campaign (which halves the rate further and does not recover automatically for the rest of that run). A large campaign on a number at RED quality, sending at a tenth of the default rate, can look alarmingly slow compared to what an earlier, faster campaign trained expectations around, without anything actually being wrong.
The second explanation is a pause the campaign already recorded but that is easy to miss if not looked for directly: a template pause, a portfolio pacing halt, a quality rating collapse to RED, a conversation quota limit, or the failure-rate circuit breaker tripping. Every one of these writes a specific reason onto the campaign, visible on the campaign detail page, rather than leaving it in an unexplained stall.
The least common, and genuinely rare, explanation is the sending worker itself being temporarily unavailable, for instance during a deploy. Sending runs on a durable, Postgres-backed queue precisely so this does not lose progress: a campaign resumes from wherever it left off once the worker returns, rather than restarting or losing recipients, though it can appear to pause briefly during the transition.
Fix
- Check the campaign's pause reason field first, before assuming anything is broken. If a reason is shown, the campaign is not stuck, it is doing exactly what it is designed to do; the reason tells you what to expect next.
- If no pause reason is shown and the status is genuinely Sending, check the number's quality rating. A YELLOW or RED rating alone explains a much slower pace than a GREEN number would show, without any pause being needed.
- Check whether the campaign recently hit a throughput limit (error 130429). If so, expect it to finish more slowly than it started, since the pacer's rate reduction after a throughput hit is deliberate and does not bounce back for the remainder of that run.
- If the campaign shows Sending with genuinely no pause reason and no progress for an extended period (well beyond what pacing alone would explain), this is the case worth contacting support about rather than continuing to wait.
- If you need the campaign to stop regardless of cause, cancel it. Cancelling is immediate and marks the untouched remainder as cancelled, never as sent, so nothing is billed or double-counted; you can build a new campaign to the remaining audience afterward.
How VGraple CRM handles it automatically
Sending itself runs on a dedicated, durable worker backed by a Postgres queue, meaning a deploy or an unexpected crash mid-campaign does not lose the campaign's place; it resumes from the recipients still pending rather than restarting the whole send or leaving it abandoned. Every one of the five conditions that can stop a campaign, a paused template, portfolio-level pacing, a collapsed quality rating, a conversation quota limit, or the failure-rate breaker tripping, writes its specific reason directly onto the campaign the instant it is detected, rather than leaving the campaign in an ambiguous "stopped, unclear why" state. Campaigns paused for a reason with a known resume time, a portfolio budget refilling at a specific hour, quiet hours ending, resume automatically and continue from exactly where they left off, with no manual restart needed. A cancelled-mid-send campaign correctly marks its untouched recipients as cancelled specifically because an earlier version of this counting logic let a cancelled campaign show zero sent while delivered and read counts kept climbing from webhooks arriving for messages already in flight, a confusing state that has since been fixed at the source.
Example
A D2C brand's 8,000-contact win-back campaign is sending at the default rate when the number's quality rating drops to YELLOW partway through, from an unrelated earlier send. The pacer halves the rate to 25/s automatically for the rest of the run. The campaign detail page shows no pause, since YELLOW slows a campaign rather than stopping it, but the remaining recipients now take roughly twice as long to finish as the first half did; nothing needs to be done, and the campaign completes on its own, just later than it would have at GREEN.
Prevention
The clearest prevention against mistaking pacing for a genuine stall is simply knowing, before launching a large campaign, what the number's current quality rating is; a campaign launched while the number is already YELLOW or RED will predictably take longer, and that is expected behaviour rather than a fault to investigate later. For campaigns sensitive to timing, avoid scheduling a very large send immediately after a smaller one to the same number, since a throughput hit from the first can leave the pacer at a reduced rate that carries into the second. Reviewing pacing, daily limit budget and auto-resume before a large launch sets accurate expectations for how long it should realistically take.
How is this different from "held" recipients?
A held recipient is a specific, individual row within an otherwise normally progressing campaign, one Meta has accepted the send for but is pacing at the message level, most commonly tied to a new or recently changed template under quality review. The rest of the campaign's recipients continue sending and completing normally around a held one; a held status describes one row's state, not the whole campaign's. A campaign that looks stuck in Sending, by contrast, describes the campaign's overall pace or a pause condition affecting everyone still pending. See messages delayed or held for the held-recipient case specifically, since the two are frequently confused but need different explanations.