Question
Does Twilio queue accepted messages when carrier congestion delays downstream delivery?
Rey Lane
0 reputation · 27 Feb 2025, 23:46 UTC
67K views
Loading…
0 reputation · 27 Feb 2025, 23:46 UTC
For current Twilio Messaging API versions, the documentation describes rate limits and sender pools, but the internal queue retention behavior during carrier congestion is not clearly bounded. When an outbound campaign pushes messages through the API, the application often receives a 202 Accepted response before the message is actually handed off to the carrier. The unresolved behavior concerns the internal Twilio queue that holds these accepted requests during downstream carrier congestion: specifically, how long the queue retains a message before it is either processed or dropped, and whether that retention window is visible to the sender.
Because rate limits are dynamic and vary by geographic region and sender type—short code, toll-free, or long code—the point at which the API begins returning 429 Too Many Requests responses is not fixed. A Messaging Service can distribute traffic across senders, but it does not bypass the per-sender capacity constraints. This makes it difficult to distinguish between application-side dispatch latency, Twilio-side queuing, and carrier-level congestion using delivery timestamps alone.
Does the delta between the API request timestamp and the sent webhook callback reliably capture the full internal queuing duration, or does it include carrier-side delays that are outside Twilio's control? What observable signals—such as status callback ordering, error code 20429 frequency, or Monitor logs—indicate that an accepted message is still inside Twilio's queue rather than already in transit? Can the retention window be inferred from webhook latency patterns without triggering additional rate-limit pressure?
35275 reputation · 28 Feb 2025, 02:38 UTC
Yes. When Twilio’s Messaging API returns a 202 Accepted, the message is placed into an internal queue. Twilio keeps it there until the carrier acknowledges receipt (status “sent”) or until the retry window expires, which Twilio documents as up to 30 days for undelivered messages. During carrier congestion the message can remain in this queue for several minutes before the sending callback is issued.
twilioqueued status in the webhook stream.sent acknowledgment is received or the 30‑day retry period ends.sent callback includes both Twilio’s processing time and carrier‑side hold.queued status without a subsequent sending status for more than a few minutes indicates the message is still in Twilio’s queue awaiting hand‑off.20429 (“carrier busy”) in callbacks signals carrier congestion but does not directly measure Twilio’s queue age.Carrier congestion causes Twilio to retry delivery. Each retry is queued internally; the queued status remains until Twilio can hand the message to the carrier. The delay you observe is usually a mix of Twilio’s queue wait (seconds to a few minutes) and the carrier’s hold (which can be longer).
queued, sending, sent, failed).queued and sending. Intervals consistently >5 minutes suggest Twilio is still queuing.20429 codes in the callback stream; a high frequency confirms carrier congestion.sent delay you observe with the 30‑day retry window to confirm retention limits.Do you receive the queued status callback for each message? If not, Twilio may be delivering directly to the carrier without queuing, altering the interpretation of any delay you see.
Twilio’s internal queue is a normal part of the delivery workflow, especially under carrier congestion. The delta between request and sent includes Twilio and carrier delays, so use the queued → sending interval as a more accurate gauge of Twilio’s queue duration.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.