# OPS-131 — A validity period shorter than the queue drops messages silently

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

- **Rule ID:** OPS-131
- **Layer:** Operational (`OPERATIONAL`)
- **Checks:** `message validity period against queue depth`
- **Severity:** LOW — Best practice. Worth fixing, rarely fatal on its own.
- **When it bites:** Falls due after approval, once you are live and sending
- **How it is detected:** External record we cannot query — reported as a warning to verify
- **Fix type:** Wait on an external system or a required interval
- **Required by:** Twilio
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/operational/ops-131/

## Why this rule exists

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 it

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.

## Example of a compliant value

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

## Check this yourself

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

1. Do the arithmetic: send size divided by granted throughput is the drain time.
2. Set 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.

## Notes

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.