Every Status a WhatsApp Template Can Be In, and What Each One Costs You

How long does template approval usually take?

Meta's own template review documentation gives one figure: "It can take up to 24 hours for an approval decision to be made" (Meta - Template review). While that decision is pending, the template sits in the PENDING state, and nothing about it is sendable yet.

That 24-hour figure is a ceiling, not an average, and Meta does not publish a typical or minimum turnaround anywhere in that documentation. Plan a launch around the ceiling, not around whatever happened to clear quickly last time.

The same page gives a second, easily confused number for a different step: if a template is rejected and you appeal instead of editing it, "the appeal will be reviewed and a decision made within 24 hours" (Meta - Template review). Initial review and an appeal on a rejection are two separate 24-hour clocks, not one.

Checked against Meta's documentation on 4 September 2026.

• How long does template approval usually take?
• What are the fourteen statuses a template can hold?
• Which rejection reasons does Meta actually publish?
• What does ARCHIVED mean, and what is the 28-day clock?
• What is the difference between LOCKED, PAUSED and DISABLED?
• When does Meta send rejection detail alongside the status?
• What does IN_APPEAL change while it lasts?
• Why does your vendor dashboard show fewer states than this?
• Which statuses should trigger an alert in your own system?
• How do you stop a working template being deleted for inactivity?

What are the fourteen statuses a template can hold?

Most integrations are written against four states: approved, pending, rejected, and maybe paused. Meta's actual webhook reference for a WhatsApp Business Account documents fourteen possible event values for message_template_status_update, grouped below by what each one means for whoever is trying to send the template, not by Meta's own internal ordering.

The diagram below groups the same fourteen statuses into the same four bands, with the archive-to-deletion window drawn as the one time-based transition in the picture, because it is the only one with a clock a reader has to act against.

Eight of these fourteen also carry a reason value, covered next, and five carry a separate other_info/title value, covered further down. Checked against Meta's documentation on 4 September 2026.

Which rejection reasons does Meta actually publish?

The same webhook reference publishes eight values for the reason field that can accompany a status change, most commonly alongside REJECTED or DISABLED:

INCORRECT_CATEGORY is the one worth a second look, because it is not really a rejection reason in the ordinary sense — Meta's template categorization documentation describes it as the outcome of Meta re-deciding what category a template actually belongs to, independent of what you selected. The mechanics of that reassignment, including the 60-day window to contest it, are their own subject: see what happens when a template gets recategorised from utility to marketing.

Checked against Meta's documentation on 4 September 2026.

What does ARCHIVED mean, and what is the 28-day clock?

Meta's webhook reference is specific about both halves of this: the event fires because the template was "archived due to inactivity," and once it does, "archived templates are scheduled for deletion after 28 days unless unarchived" (Meta - WhatsApp Business Account webhook reference).

A template you have not sent in a while can go from working to permanently deleted with no rejection, no policy violation, and no human decision anywhere in the chain — only elapsed time. Nobody edits the template, nobody violates a policy, and the WhatsApp Manager UI shows nothing alarming until the day it is simply gone.

Unarchiving inside the 28 days restores the template to whatever status it held before archival — UNARCHIVED in the table above — which for a template that was healthy beforehand generally means it goes back to APPROVED. Miss the window and there is no previous status left to restore; DELETED is not reversible.

Checked against Meta's documentation on 4 September 2026.

What is the difference between LOCKED, PAUSED and DISABLED?

These three sound like synonyms for "you cannot use this template right now," and Meta's documentation treats them as three distinct mechanisms with three distinct recovery paths.

PAUSED is a quality-rating consequence, and Meta's template pausing documentation gives an escalating schedule: "Paused for 3 hours" the first time a template's quality rating drops to Active - Low quality, "Paused for 6 hours" the second time, and on the third instance the template is disabled outright (Meta - Template pausing). The same page notes that under Meta's Template Pacing system, in effect for all businesses since October 2023, a paused template must be manually unpaused through the API or WhatsApp Manager rather than recovering on its own once the clock runs out — worth confirming against your own account rather than assuming a pause will clear itself.

DISABLED is what a third low-quality instance turns into, or what Meta's webhook reference separately calls out as disabling "due to user feedback." Unlike a pause, there is no timer; Meta's template review documentation says the recovery path is the same as for a rejection — edit and resubmit for approval.

LOCKED is the odd one out: Meta's webhook reference defines it only as a template that "cannot be edited," and neither that page nor Meta's template quality or template pausing documentation states what specifically triggers it. Treat it as: whatever the cause, do not build a retry loop that assumes editing will succeed — check the status again before attempting a change, and if it persists, that is a case for Meta's own support channel rather than a guess in your own code.

Checked against Meta's documentation on 4 September 2026.

When does Meta send rejection detail alongside the status?

Most reason values above arrive as a bare label — PROMOTIONAL, SCAM, ABUSIVE_CONTENT — with no further structure attached. One reason is different: when reason is INVALID_FORMAT, Meta's webhook reference documents a companion rejection_info object carrying its own reason and recommendation fields, giving actionable detail about what specifically was malformed and what to change.

That asymmetry matters for how you design an alert. A handler written to always expect rejection_info will find it absent for every other reason value; one written to never expect it will silently drop the one payload actually useful enough to route straight into a fix-it message for whoever built the template. Branch on the reason value first, and only read rejection_info when it is INVALID_FORMAT.

Checked against Meta's documentation on 4 September 2026.

What does IN_APPEAL change while it lasts?

Meta's webhook reference lists IN_APPEAL as its own event value, meaning a rejected template that its owner chose to contest rather than edit. Meta's template review documentation adds the timing commitment: "the appeal will be reviewed and a decision made within 24 hours."

What Meta's documentation does not state is whether the original rejected content becomes sendable at any point during that window, or whether IN_APPEAL is purely a waiting state with the same restrictions as REJECTED. Nothing in either page addresses it, so this article will not guess at it either — assume the template stays unsendable until the appeal resolves one way or the other, because that is the safer default and the only one Meta's own text supports.

An appeal that succeeds should produce an APPROVED (or REINSTATED, depending on what triggered the appeal) event on the same webhook field; one that fails presumably returns to REJECTED, though Meta's documentation does not spell out the exact terminal event for a failed appeal either. Log the transition either way rather than assuming which one it will be.

Why does your vendor dashboard show fewer states than this?

Every WhatsApp management tool sits between you and this webhook, and every one of them has to collapse fourteen raw event values into something a template list can render in one column. WabaCRM's own templates screen is no exception — it shows Approved, Pending and Rejected as the visible states on the row, which is a deliberate simplification of the same fourteen values documented above, not a smaller set that Meta itself publishes.

That simplification is reasonable for a table row — nobody wants a LIMIT_EXCEEDED badge sitting next to a TAG_CONTENT_MISMATCH one in the same visual language as Approved — but it is exactly why this reference page needed writing. A dashboard that only ever shows three or four states cannot tell you a template was archived for inactivity, locked against editing, or sitting in an appeal, because none of those has anywhere to render. The underlying data exists in Meta's webhook regardless of what any dashboard chooses to surface, and a handler subscribed directly to message_template_status_update sees all fourteen whether or not the UI in front of it does.

Which statuses should trigger an alert in your own system?

Not every one of the fourteen values needs a human notified. Some are routine, some are informational, and a handful genuinely need attention before they turn into a missed send.

Everything in the left column either stops a template from sending right now, or starts a clock that ends in permanent deletion. Everything on the right is either the normal outcome of a submission or a recovery you already asked for. Wiring an alert only to the left-hand list keeps the signal-to-noise ratio sane on an account running more than a handful of templates.

How do you stop a working template being deleted for inactivity?

The 28-day archive clock is the one failure mode in this whole list that costs nothing to prevent and nothing to notice if you never look. Two approaches, and they are not mutually exclusive.

The reactive approach is watching the webhook: subscribe to message_template_status_update, catch the ARCHIVED event the moment it fires, and unarchive immediately if the template is still one you intend to keep using. This works, but it depends on nobody muting or ignoring that specific alert — which circles back to the previous section's point about deciding in advance which events deserve a human's attention.

The preventive approach is simpler: a template that is actually being sent regularly never accumulates the inactivity Meta is archiving against in the first place. If a template only fires occasionally — a seasonal promotion, an annual renewal notice — that irregular cadence is exactly the shape Meta's archival logic is watching for, so build a periodic check (monthly is enough) against WhatsApp Manager or the API for any template whose usage is naturally sparse, rather than discovering the gap only when a campaign against it fails. A campaign that depends on a template stalling mid-send because the template quietly disappeared weeks earlier is a slower version of the failures covered in what actually caps a WhatsApp broadcast — the send never even reaches the point where a rate limit would matter.

None of this needs a paid feature to solve; it needs the webhook wired up and someone reading it. Whether that reading happens through Meta's own WhatsApp Manager, your own code against the API, or a shared inbox product that surfaces template health on the same screen your team already checks daily, the underlying fourteen-value contract from Meta is identical either way — see the templates and message catalogue overview for how that surfaces day to day, and what a Tech Provider does and does not bill for if the next question is what fixing a broken template costs beyond the time.

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.