Template Approved, Messages Accepted, Nothing Arriving

What is template pacing, and why does Meta do it?

Everything about the send looked fine. The template shows Approved. The API returned success on every message. Your own logs say sent. And the phone the campaign was aimed at never buzzed.

The mechanism responsible for that gap has a name, and Meta states it in one sentence: "Template pacing is a mechanism that allows time for customers to provide early feedback on templates" (Meta - Template pacing). It is not a bug in your integration, not a delivery failure Meta owes you an explanation for, and not the same thing as a template being rejected. It is a deliberate holdback built into how a new or recently-changed template is allowed to reach an audience at all.

The reason it exists is upstream of any one business's campaign. WhatsApp users who suddenly start receiving a business message they don't recognize, don't want, or find irrelevant will block the sender, report it as spam, or simply stop reading - and that reaction degrades the sending number's quality rating for every template it sends, not just the new one. Pacing is Meta reading the reaction to a small slice of an audience before deciding whether the rest of that audience gets the same message. Nothing about this shows up as an error in isolation; it shows up as a send the API accepted and a recipient who received nothing.

Checked against Meta's documentation on 4 September 2026.

• What is template pacing, and why does Meta do it?
• Does pacing apply to utility templates as well as marketing?
• What happens to a message that gets held?
• How would you see pacing in your own send records?
• When does a paced template start flowing normally again?
• Which templates are exposed to pacing, and for how long?
• What do the pause values in the status webhook mean?
• How is pacing different from a quality-rating problem?
• Why do vendor dashboards describe pacing differently from Meta?
• What is the safest way to launch a brand-new template?

Does pacing apply to utility templates as well as marketing?

This is the point where vendor documentation disagrees with itself, and it matters because the two template categories carry different assumptions about urgency. A marketing template is a broadcast; a utility template is usually an order update, a delivery notice, an OTP-adjacent confirmation - the kind of message a business assumes gets through because it is transactional rather than promotional. That category is not fixed at your own discretion either: a template you file as utility can be recategorized as marketing after the fact, which is a separate mechanism from pacing but touches the same templates.

Meta's own sentence removes the ambiguity: "Template pacing is valid for marketing and utility templates" (Meta - Template pacing). It names both categories in the same clause, with no qualifier attached to either one.

The scope of which templates are exposed is also explicit, and it is wider than "brand-new only": "Newly created templates, paused templates that are unpaused, and templates that may have been created previously but don't have a GREEN quality rating are potentially subject to pacing" (Meta - Template pacing). Read literally, that is three separate doors into pacing, not one: a template can be new, or it can be old and simply carrying a YELLOW or RED quality rating rather than GREEN, and either way it is a candidate. Meta attaches a specific duration to only one of these cases, and only for utility templates - covered further down, under "Which templates are exposed to pacing, and for how long?"

If a page you're reading states flatly that pacing "only applies to marketing templates," treat that as a claim to verify, not a fact to plan around - Meta's own documentation, quoted above, says otherwise. A utility template that has previously been paused, or that was only just approved, sits inside the same mechanism a first-time marketing broadcast does.

Checked against Meta's documentation on 4 September 2026.

What happens to a message that gets held?

"Held" sounds like a queue. It is not. Meta's documentation is specific about what a held message becomes, and the two outcomes are not symmetrical.

If the early signal is good, the message flow opens up: "Once Meta receives a good quality signal, subsequent messages using that template will be scaled to the entire target audience" (Meta - Template pacing). Recipients who were held simply start receiving the message as the rollout continues.

If the early signal is bad, the held messages do not sit and wait for a retry. "Each held message will be dropped and trigger a messages webhook with \"status\":\"failed\" and \"code\":\"132015\"" (Meta - Template pacing). That is the mechanical fact worth sitting with: a dropped message is a failed send, reported the same way any other failure is reported, on the same webhook channel every other delivery status update arrives on - it simply arrives with a different code (132015, which Meta's own error reference describes as "Template is paused due to low quality so it cannot be sent in a template message").

There's a third outcome the two-sided "good signal / bad signal" framing leaves out, and Meta names it directly: "if our internal guardrails are reached before a template has received enough feedback to change its quality to high or low, the held messages will be released normally along with any appropriate messages webhooks" (Meta - Template pacing). In other words, pacing does not wait forever for a verdict - if neither a clear positive nor a clear negative signal arrives, Meta's own internal limits eventually let the held messages through anyway.

That three-way fork is why a flowchart with a single arrow from "approved" to "delivered" is the wrong shape here. There is no single next step after approval - three branches exist, and which one a send lands on is not visible from the template's own status.

Checked against Meta's documentation on 4 September 2026.

How would you see pacing in your own send records?

Pacing does leave an immediate trace. Meta states: "The immediate response from the messages endpoint will indicate if the message was sent or held with the new message_status property" - specifically, "Cloud API will always include a message_status property that will have a value of accepted for messages that are processed, and held_for_quality_assessment for messages that are held" (Meta - Template pacing). The two outcomes are distinguished in the very same send response, by a field that is easy to never read: an integration that checks only the HTTP status code sees a paced, held message as no different from a normally accepted one, because both return success at the transport level - that is the real reason this goes unnoticed, not that the two are indistinguishable.

A per-recipient status table is still the practical place to see pacing happen day to day, because most systems ingest delivery outcomes from webhooks into a report rather than reading every send response live. A completed broadcast recording six figures - recipients, sent, delivered, read, failed, skipped - alongside a reason on every failed or skipped row turns "nothing arrived" from a mystery into a line item you can point at.

On a real send, that row would show a failure against error 132015 for recipients caught in a dropped batch, beside other rows that delivered cleanly on the same broadcast - pacing acts on a share of the audience, not the whole of it. If your own reporting shows only a single aggregate "sent" figure and never breaks failures out by reason code, you are structurally unable to see pacing happen even when it is the cause: the campaign reads as fully sent while part of the audience received nothing, and the only trace is a webhook your system may not be storing.

When does a paced template start flowing normally again?

There is no timer published for this, and it is worth saying directly: Meta does not document an automatic, time-based release from pacing. No page states "pacing lasts N hours" or "sends resume after N minutes." What ends a paced state is one of the three outcomes from the section above - a positive signal, a negative signal, or an internal guardrail being reached - and Meta gives no fixed clock for any of them.

This is different from template pausing, which does carry documented durations: a template that reaches the lowest quality rating is paused for a stated period on its first occurrence, a longer period on a second occurrence, and disabled outright on a third. Pausing and pacing are related mechanisms - Meta's quality-rating documentation states that "quality ratings factor into template pacing and template pausing, which can affect template delivery" (Meta - Template quality rating) - but pacing itself, the holding-and-releasing behavior on a fresh or unrated template, is not described with a clock. It resolves on signal, not on schedule.

That distinction matters for anyone tempted to wait it out. Waiting does nothing on its own; the substance of what the audience is receiving is what produces the signal that ends the hold.

Checked against Meta's documentation on 4 September 2026.

Which templates are exposed to pacing, and for how long?

Restated precisely, because the exact wording carries the boundary. Meta's general description - which covers marketing and utility templates alike, with no duration attached - names three categories: "Newly created templates, paused templates that are unpaused, and templates that may have been created previously but don't have a GREEN quality rating are potentially subject to pacing" (Meta - Template pacing).

That is three distinct categories, and only the first one is what most people picture when they hear "new template":

A template with a long send history and a GREEN quality rating is the one category this list does not name, and by omission is the template least likely to be paced on any given send.

The seven-day duration that often gets attached to this list is real, but it is documented only under a separate heading, "Utility template pacing," and only once a further condition is met. Meta's own wording: "Utility templates are subject to pacing only if you have had a utility template paused. Once a utility template has been paused, newly created templates, paused templates that are unpaused, and templates that may have been created previously but don't have a GREEN quality rating are potentially subject to pacing for the next 7 days" (Meta - Template pacing). Two things follow: the seven-day window is a utility-template-specific rule with no equivalent stated for marketing templates, and it is not triggered merely by a template being new - it requires the account to have already had a utility template paused at some point. A brand-new utility template on an account with no prior pause sits in the first, undated category above.

Quality ratings themselves are documented in four bands: GREEN ("high quality... little to no negative feedback"), YELLOW ("medium quality... negative feedback from multiple WhatsApp users, or low read-rates"), RED ("low quality... negative feedback from multiple WhatsApp users, or low read-rates"), and UNKNOWN ("a quality score is still pending, because it has yet to receive WhatsApp user feedback or read-rate data") (Meta - Template quality rating). Notice that UNKNOWN alone is enough to put a template in the exposed category - a template does not need a bad rating to be paced, it only needs the absence of a GREEN one, which is the default state of anything that hasn't accumulated feedback yet. Every status and rating a template can carry is catalogued separately from pacing, since a paced template and a merely-new one can show the identical GREEN-less state on the surface.

Checked against Meta's documentation on 4 September 2026.

What do the pause values in the status webhook mean?

If a paced template's negative signal turns into an actual pause, the change arrives on the message_template_status_update webhook as an event with the value PAUSED (Meta - message_template_status_update webhook reference). That single event value covers more than one situation, which is why the payload carries a further field distinguishing them: a title naming which kind of pause occurred, documented with the values FIRST_PAUSE, SECOND_PAUSE, RATE_LIMITING_PAUSE, and UNPAUSE.

A separate DISABLED event covers the case where repeated low-quality pauses end in the template being switched off entirely rather than paused again.

Reading this field rather than only the outer event value matters: PAUSED alone tells you a template stopped sending, but title tells you whether it is a first or second pause, and whether the cause was a quality verdict or a rate limit - different situations arriving under the same top-level event name.

Checked against Meta's documentation on 4 September 2026.

How is pacing different from a quality-rating problem?

The two get described as one thing in casual conversation. They are related, but not the same mechanism, and the difference is which templates each one can touch.

Pacing is available to any template that lacks a GREEN quality rating, including one that has simply never sent enough volume to earn feedback yet - a template can be paced without having done anything wrong. A quality-rating pause, by contrast, is a consequence: it follows an existing GREEN or YELLOW template actually earning enough negative feedback to drop to the lowest band, and it carries documented, escalating durations on repeat occurrences rather than resolving on an undocumented signal.

Put another way: pacing is a holding pattern applied to templates Meta hasn't yet formed a confident opinion about. A quality-rating pause is a penalty applied to a template Meta has formed a confident, negative opinion about. A template can pass through pacing cleanly - full release on a good signal - and separately, months later, still earn a quality-rating pause if its content or targeting degrades after it has already scaled. One is evaluation; the other is enforcement. See WabaCRM's guide to WhatsApp broadcast limits for how the account-wide messaging tier sits alongside both of these as a third, separate ceiling.

Why do vendor dashboards describe pacing differently from Meta?

Search for this symptom and most of what surfaces is a vendor's own help-center page, describing pacing in the vocabulary of its own dashboard rather than Meta's - a reasonable thing for a vendor to do, since their support page exists to explain what their customer sees in their UI. It is also why the scope question above has a genuinely contested answer online: one help page states pacing is marketing-only, another says it covers both categories, and neither cites the sentence that actually settles it.

The settling sentence is Meta's, not any vendor's: template pacing is valid for marketing and utility templates. A vendor's dashboard can choose not to surface a distinction Meta's API still enforces, so its absence there is not evidence the platform doesn't apply it. When a mechanic is asserted by a vendor's documentation but not stated in Meta's own, treat it as the vendor's claim - and when the two disagree, Meta's page is the one whose wording will still be accurate after any given vendor's dashboard changes.

What is the safest way to launch a brand-new template?

Nothing in Meta's documentation converts this into a guarantee, but the mechanism points at a specific practice: since release depends on an early positive quality signal from actual recipient behavior, the templates most likely to clear pacing quickly are the ones whose first sends go to people who will read and respond without friction.

A few things follow directly from the mechanism rather than from general marketing advice:

• Launch new templates against your most engaged, most recently active contacts first, not a full list pulled cold.
• Watch the per-recipient status on the report rather than the top-line "sent" count - a status:failed row with code 132015 is the signal that a batch was dropped, not merely delayed.
• Check whether the send would have hit the account's messaging limit anyway before assuming pacing is the only mechanism throttling a launch - the two can compound on the same campaign.
• Do not assume a GREEN-rated sibling template protects a brand-new one - pacing is documented per template, so an established template's good standing does nothing for one that has just been approved.
• If you send utility templates and one of them is ever paused, expect the documented seven-day exposure window to apply to your utility templates afterward - that clock is specific to having had a utility template paused, not to a template simply being new.

A shared inbox and a per-recipient campaign report are what make any of this checkable rather than theoretical - a dispatcher that tracks status per recipient, not only per campaign, is what turns "some of the audience got nothing" from a guess into a line you can read directly off the send record. See WabaCRM's pricing and plan structure and the feature overview for how campaign reporting and the shared inbox fit together, or read how the WhatsApp Business API is priced in India for the message-fee side of running templates at any volume - this page deliberately does not restate a per-message rate, because a stated rate ages the moment Meta revises it.

If the same template keeps landing in a pause rather than clearing pacing cleanly, that pattern is closer to the territory covered in WabaCRM's guide on account restrictions than to pacing itself - worth reading once pacing stops being the likely explanation.

Every Meta quotation on this page was read from Meta's own documentation on 4 September 2026. Meta changes that documentation without notice; the linked pages are authoritative and this one is not.