On 24 September, Twilio's status page (which also covers SendGrid) logged nine separate incidents, mostly SMS delivery problems to specific carriers in different countries, plus a short Event Streams disruption. The longest, SMS delays to Datora in Brazil, ran 116h 54m. These were faults on Twilio's side, not yours.
Started
06:56 UTC
Duration
Lasted 21h 51m
Source
IsDown
Next time
SendGrid is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
What happened?
Twilio's status page recorded nine distinct incidents starting at 06:56 UTC on 24 September, with 66 status updates posted across them in total. Most were carrier-specific SMS problems: delivery failures to Telkomsel in Indonesia, delays to Datora in Brazil, delayed delivery receipts to MTN in Cameroon and to Ooredoo in Algeria, and delivery delays and failures to MTS in Belarus. None of these touched email sending through SendGrid's core API. Two incidents sat closer to SendGrid proper: a Link Branding creation failure returning HTTP 500 errors when Auto SSL was enabled, running from 16:22 to 18:26 UTC, and an Event Streams service disruption from 20:40 UTC that Twilio said could cause event data loss or delays, resolved at 02:24 UTC the next day. The Datora Brazil SMS incident was the longest of the day at 116h 54m, moving through investigating, identified, and monitoring states repeatedly before Twilio marked it resolved. One user report fell in this window: from Brazil at 21:48 UTC, "Sendgrid website not loading." No other user reports were filed during the day. Twilio's own updates are the only record of cause and timing here, and for incidents like the Link Branding bug, Twilio states the fix was deployed and monitored before being marked resolved. For the SMS and carrier incidents, no further explanation of root cause appears beyond "identified" status.
Learning
UptimeRobot's own checks against SendGrid's API from EU and NA regions held at 100% uptime across 24 hours, 7 days and 30 days, and this incident was not registered against those probes. That is consistent with what Twilio published: the day's problems were concentrated in carrier-specific SMS delivery and in auxiliary features like Link Branding and Event Streams, not in the core API your product calls. A green external check tells you the endpoint you depend on answered every request it was sent. It does not tell you whether a downstream carrier dropped messages or whether a secondary feature like transcript processing was delayed, because those failures live inside the provider's infrastructure, not at the edge you can probe. If your product sends SMS through specific carriers or relies on Event Streams or Link Branding, you could have been affected without any of your own monitoring showing a problem. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
