TL;DR
On September 19, some beta users sent Orbit messages that were read and processed but never received a reply. In Messages, Orbit appeared to type intermittently for an extended period. The underlying work had completed; the final delivery hadn't.
I traced the interruption to a sending limit on the managed shared messaging infrastructure. Orbit treated that hard limit like a temporary network error and retried indefinitely. I restored delivery by moving the beta to a dedicated line and migrating every active account and task route.
Impact
- Inbound messages continued to reach Orbit and were marked as read.
- At least two completed replies were rejected before they reached users.
- Repeated delivery attempts caused the typing indicator to appear and disappear without producing a message.
- Account data, memories, connected services, reminders, and longer-running tasks remained intact.
Timeline · Eastern time
The first confirmed reply completed internally but was rejected by the messaging provider.
I received reports that Orbit was reading messages and repeatedly typing without responding.
Logs isolated the failure to outbound delivery and identified the provider’s sending-limit response.
Orbit connected successfully to newly provisioned dedicated messaging infrastructure.
I migrated a single account first and verified delivery on the dedicated line.
Every active beta account and its live task routes had been migrated; all handoff messages delivered on their first attempt.
Root cause
The immediate cause was straightforward: the shared messaging service stopped accepting outbound messages after its sending limit was reached.
The longer outage was mine. Orbit’s gateway classified every provider failure as retryable. A hard account limit therefore entered the same retry loop as a brief connection drop. Because typing starts before a turn is processed, each retry made Orbit look busy even though delivery could not succeed.
Reactive replies also relied on an in-memory delivery path. The completed responses were safely recorded with their conversations, but they were not sitting in a durable outbound queue that could wait for the provider to recover.
Resolution
- Upgraded Orbit to dedicated messaging infrastructure.
- Moved every active account to one permanent Orbit number.
- Migrated active reminders, watches, workflows, and pending approval routes with each account.
- Sent a clear handoff message from the new line and verified every delivery.
What changes next
Dedicated infrastructure removes the shared-plan failure mode, but capacity was only the trigger. I am also hardening the delivery path itself.
- Persist every reply to a durable outbox before acknowledging the inbound message.
- Classify hard provider limits as terminal incidents instead of retrying forever.
- Stop typing immediately when delivery cannot proceed and surface a clear operational alert.
- Track delivery health and queue depth in dashboards.
I’m glad Orbit broke
Orbit is supposed to hold onto the loose end. A message that looks alive but never arrives breaks that promise in a frustrating way, but I’m glad it was found. I’m sharing this because I think it is a useful lesson and it is fun to see how it was fixed.