A validity period shorter than the queue drops messages silently

The requirementstatement

The message validity period must be long enough for the message to survive queueing at the sender's actual throughput.

Severityseverity
LowLOWBest practice. Worth fixing, rarely fatal on its own.
When it bitesphase
After you are livepostFalls due once you are sending: STOP handling, quiet hours, suppression, record retention.
What is checkedobject
message validity period against queue depth
Where it liveslayer
OperationalOPERATIONAL
How Ekas settles itdetectability
External recordEXTERNAL_DATA
The fact that settles it lives in a register we cannot query, such as the IRS file, a postal database, or another provider’s tenant. Reported as a warning with the evidence to check, not as a pass.
What the fix involvesfailureClass
Wait on someone elseTERMINAL_EXTERNAL
Needs an external system or a waiting period, such as IRS propagation, a vetting result, or a carrier queue.
Who requires itauthorities
Twilio
When it appliesapplicabilityText
Applies to every 10DLC registration.

Why this rule existsrationale

Validity period is a per-message expiry, so a large send at a modest throughput will have messages expire in the queue before they are ever attempted — and they are discarded rather than failed, so the delivery report shows nothing wrong. The default is short relative to the time a hundred-thousand-message send takes at fifteen a second.

How to fix itremediation

Divide the send size by the granted throughput to get the drain time, and set the validity period comfortably above it. Done when the last message in a large send is still valid when its turn arrives.

A compliant exampleexample

200,000 messages at 60/second ≈ 56 minutes to drain → validity period 4 hours, not the 15-minute default.

Check this yourselfattestation

No tool can settle this one for you. Here is the check, and what wrong looks like.

At your granted throughput, will the last message of your largest send still be valid when its turn arrives?

  1. 1Do the arithmetic: send size divided by granted throughput is the drain time.
  2. 2Set the validity period comfortably above it. The default is fine for small sends, which is why this only appears at scale.

What wrong looks like: Messages expire in the queue before they are attempted and are discarded rather than failed, so the delivery report shows nothing wrong at all.

Notesnotes

A per-message parameter in the sending API. What the user has to check is the arithmetic for their largest send — the default is fine for small ones, which is why the problem only appears at scale.

Rules you will hit next

Other operational rules at the same severity. A registration is judged as a whole, not rule by rule.

All operational rules

OPS-131 is one of 139 operational rules in the 915-rule 10DLC registry. Free to cite under CC BY 4.0.

Reading the rules is the easy part.

Ekas runs every rule that gates approval, 823 of these 915, against your registration before it reaches the carrier. It reads your site, your policy pages and your opt-in the way a reviewer would, and hands you the fix, not just the verdict.