SendGrid statusLiveFetched seconds agoSource: status.sendgrid.com
Is SendGrid down?
Live status check · All systems operational
Live status pulled from status.sendgrid.com, cached and revalidated every 60 seconds. Below: the components that can break, what to do during an incident, and how to keep your scheduled jobs running independently.
About SendGrid status
SendGrid is Twilio's transactional and marketing email API, used by a huge slice of SaaS for password resets, receipts, and bulk sends. When it degrades, sends get deferred and webhook events (delivery, bounce, open, click) start lagging behind what your app thinks has happened.
Components and surfaces that can break
- Surface 01
Outbound Mail Send API (POST /v3/mail/send) and SMTP relay.
- Surface 02
Inbound Parse webhooks (incoming email piped to your endpoint).
- Surface 03
Event webhooks (delivery, bounce, open, click, spam report).
Recent SendGrid incidents
SendGrid maintains a public incident history. Read the latest entries to see whether you're hitting a known issue, and look at the post-mortems for context on how long similar incidents typically take to clear.
What to do if SendGrid is actually down
Queue sends client-side, do not drop them
If /v3/mail/send returns 5xx, your app should not lose the user-facing action. Persist the payload to your DB or job queue, mark the request as 'will email shortly', and retry once SendGrid recovers. POST /mail/send is the trigger, so a failed request means the message was never accepted.
Check whether sending, webhooks, or the dashboard is degraded
status.sendgrid.com lists the Mail Send API, Event Webhook, Inbound Parse, and Dashboard as separate components. An event-webhook brownout still lets you send mail; you are just temporarily blind to delivery and bounce events. Confirm the affected component before changing your integration.
Cross-check the Twilio parent status page
SendGrid is owned by Twilio and a Twilio-side networking or identity incident sometimes correlates with SendGrid symptoms. If status.sendgrid.com is green but everything feels off, glance at status.twilio.com before tearing apart your own code.
Keep firing through the incident
Schedule your own SendGrid health check with Crontap
Scheduled email digests, daily transactional batches, and weekly reports are HTTP cron against your own endpoint that wraps SendGrid. Crontap fires the endpoint that builds the digest and calls SendGrid, retries on 5xx, and surfaces the response body in the failure alert so a transient SendGrid blip does not kill the whole run.
External HTTP cron hits your endpoint on the cadence you pick, stores every response, and emails you the moment a run fails. Pro schedules down to 1 minute; $3.25/mo annual flat for unlimited jobs.
Go deeper
SendGrid status: FAQ
- Where can I see the official SendGrid status?
- status.sendgrid.com publishes component-level status for the Mail Send API, SMTP relay, Event Webhook, Inbound Parse, and the Dashboard. The history page and Atom feed at /history.atom track past incidents with timestamps and post-mortems.
- Will SendGrid retry sends that failed during an outage?
- No. POST /v3/mail/send is the trigger, so if it returned a 5xx the message was never accepted into SendGrid's pipeline. Your app has to retry the request once SendGrid is healthy again. SendGrid does retry downstream delivery to mailbox providers, but only after a send has been accepted.
- How do I make a scheduled email digest reliable?
- Schedule a Crontap job against your /jobs/send-digest endpoint at the cadence you want. Inside the endpoint, build the digest, call SendGrid, and return 5xx if SendGrid fails. Crontap retries 5xx on a backoff so a transient SendGrid blip does not kill the run, and the failure alert includes the SendGrid error body so you can debug without digging through their dashboard.