Summary

  • Twilio opened incident bj32d99klw04 at 13:17:38 UTC on 2 August for SMS delays and failures toward Safaricom subscribers in Kenya.
  • The affected origin was bounded to a subset of Twilio alphanumeric sender IDs and long codes, not all Twilio SMS traffic or all Kenyan mobile messaging.
  • Twilio said it identified the cause at 13:52:28 UTC but did not disclose the cause or the ownership boundary.
  • At 14:51:54 UTC, 94 minutes after opening, Twilio said it had observed recovery and moved to monitoring service stability.
  • At the fixed cutoff of 15:12:10 UTC, monitoring had lasted about 20 minutes and the incident was not marked resolved.
  • Twilio published no message denominator, delay distribution, failure rate, retry outcome, business loss or security finding.

The route boundary is the most useful fact

The status wording is unusually specific about where the symptom began and ended. It points to messages sent from a subset of Twilio alphanumeric sender IDs and long codes toward subscribers on Safaricom’s Kenyan network. That is a route-class incident, not evidence that Twilio’s entire messaging platform or Safaricom’s network failed.

The word “subset” matters. Customers using another sender type, destination network or route may have been unaffected. Conversely, a business using one of the affected origins could have experienced a high failure rate even if the platform-wide share was small. No denominator lets readers reconcile those two views.

Three state changes, one undisclosed mechanism

Twilio began with investigation at 13:17:38 UTC. At 13:52:28, roughly 35 minutes later, it said the cause had been identified and work was under way. At 14:51:54, about 94 minutes after opening, it reported observed recovery and entered monitoring.

Those transitions show increasing operator confidence but do not disclose the repair. The cause could sit in routing, sender registration, filtering, an interconnect or another dependency; the source gives no basis for choosing. “Identified” is an operator state, not a public diagnosis.

Recovery was observed, not yet certified by closure

At the 15:12:10 UTC cutoff, Twilio had watched the recovered route for about 20 minutes. That supports a statement that delivery was recovering and stability was under observation. It does not support a claim that the incident had been formally resolved by then.

This distinction is operationally important for time-sensitive messages. A route can show aggregate recovery while delayed queues, expired messages or individual sender configurations still need reconciliation. Twilio supplied no final queue state or delivery-receipt analysis.

SMS failure can become a workflow failure

Businesses use application-to-person SMS for authentication codes, alerts, appointment reminders, delivery updates and customer service. Delay can be as damaging as permanent failure when a code expires or a notice arrives after the action it was meant to trigger.

The status page does not say which use cases were affected. It also does not establish lost revenue, missed appointments or security bypass. Customers must connect the incident window to their own message logs before assigning business impact.

Retries require message-level discipline

A sender should identify messages submitted after 13:17 UTC, separate pending, failed and delivered states, and check carrier delivery receipts. Blindly resending every uncertain message can create duplicate alerts or codes, while doing nothing can leave a customer without a critical notice.

The safe response depends on the message’s idempotency and expiry. Authentication messages may need a fresh token; transactional notifications may require a deduplicated retry; informational messages may no longer be useful. The public incident supplies no universal retry instruction.

The repeated title is not the same incident

Twilio used essentially the same title for incident nv815k5xyy4q on 29 July. The 2 August event has a different incident ID and a different timestamp sequence. Repeated route wording shows recurrence on the same commercial path, not a continuation of the older administrative object.

That recurrence makes a post-incident explanation more valuable. Customers would benefit from knowing whether the two events shared a cause, whether a previous corrective action failed and how route health is tested. No such linkage appears in the available record.

Sources