Communication Status
Everything is up.
Messaging and email infrastructure fails in a way that delays rather than refuses, which is why these incidents are so often noticed late. The API accepts your request and returns success, then the sending pipeline backs up behind a carrier or a mailbox provider. Nothing errors. Password resets, receipts, and one-time codes simply arrive minutes or hours after they should, by which point the user has given up.
Because delivery depends on third parties, the blast radius is usually narrow and invisible from outside. An SMS provider can be delivering perfectly everywhere except one country, or one carrier inside one country, and an email provider can be reaching most inboxes while one large mailbox provider is deferring everything. A single status verdict cannot express that.
Team chat and video are the opposite: highly visible, and split across separate systems. Voice, messaging, and file handling each fail independently, so calls can drop while chat is untouched.
- up
- slow
- down
- no reading
Common questions about messaging and email providers
Check whether they arrive late rather than never, since carrier-level delays are far more common than outages and the API will have accepted the message either way. Try a number on a different carrier, or a different country if you can. If one carrier is slow and another is instant, the problem is a delivery route rather than the provider.
Acceptance and delivery are separate steps. The API confirming receipt only means the message is queued. Look at the provider's delivery logs or webhooks for the actual outcome, and check whether one recipient domain is deferring. A single mailbox provider deferring mail is not the sending provider being down.
Voice and video use separate infrastructure from messaging, and are frequently regional. An incident affecting one voice region leaves text chat completely unaffected, which is why the linked official status page usually lists them as separate components.