Degraded performance
SendGrid reports degraded performance on Mailsend Comms API, API v3, SMTP, and API v2. The incident started on 13 November 2026 at 15:24 UTC. SendGrid is investigating and gives no workaround.
State
Components degraded
Started
Ongoing for
30 min
Worst impact
Degraded
Timeline
1 updateComponents degraded
30 min 100%
Updates
Times in UTCAs posted by SendGrid
Affected components
4SendGrid in the last 90 days
Full historyIncidents in 90 days
75
Days with an incident
43
Median duration
9 h 1 min
This incident
94% shorter than the median
Other SendGrid incidents
All incidentsSendGrid·Degraded performance
SendGrid reported degraded performance on Mailsend: Comms API, API v3, SMTP, and API v2. SendGrid reports that the incident is resolved. The incident lasted 3 minutes.
SendGrid·Email Delivery Delays to Microsoft Inboxes
SendGrid reported delayed email delivery to Microsoft inboxes. The problem affected the Comms API, API v3, SMTP, and API v2. SendGrid identified the issue and later marked it resolved. The outage lasted about 19 hours and 42 minutes.
SendGrid·Email Template Editor Issues
SendGrid Marketing Campaigns had a problem with the email template editor. HTML entities changed to spaces, links changed, and some template content did not render after save or preview. SendGrid reports the incident resolved. It lasted 106 minutes.
SendGrid·Delayed Email Validation History
SendGrid reported delayed Email Validation history and statistics in the SendGrid UI. The Logs and TWILIO EMAIL - Logs components were degraded. SendGrid resolved the incident on 4 November 2026 after 168 minutes.
SendGrid·MMS Delivery Delays from a Subset of Twilio Long Codes to Multiple Small Carriers in United States
SendGrid reported MMS delivery delays from a subset of Twilio Long Codes to multiple small carriers in the United States. The affected components were MMS Long Code, North America. SendGrid resolved the incident after 78 minutes.
Follow SendGrid
Your coding agent knows when SendGrid is down, and tells you when a failure is theirs, not yours. You can also get SendGrid incidents in a feed reader or in Slack.
Install the outages.live MCP server, so that when something breaks you can tell if the cause is a provider we depend on and not my code. It reads the official status pages of cloud, AI, payment and developer providers and gives you their incidents as MCP tools.
Add it as a remote MCP server named "outages" at https://outages.live/mcp (Streamable HTTP, no authentication), with your CLI command or your MCP config file.
Then:
1. Make sure it connects and shows the tools get_provider, list_feed and send_feedback.
2. Call get_provider with "sendgrid" and tell me if SendGrid has a problem right now.
3. From now on, when a call to a third-party service fails or becomes slow, call get_provider for that service before you change my code.Paste this into any coding agent. It adds the server with its own MCP setup.
https://outages.live/feed.xml?providers=sendgrid/feed subscribe https://outages.live/feed.xml?providers=sendgridFAQ
Go from tracking outages to fixing production issues with Polylane.
Try Polylane