Is SendGrid down right now?

While you wait: the SendGrid incident checklist

1. Name the dependency precisely. SendGrid is your cloud, data or AI runtime dependency. Identify which of these surfaces is actually in the production path: regional APIs, managed data paths, model calls, control planes and background jobs.
2. Confirm the affected path. Use SendGrid's component and incident detail, then compare at least two regions or endpoints and separate control-plane errors from requests already running in the data plane.
3. Bound every retry. Cap concurrency, use exponential backoff and retain idempotency where applicable. An upstream incident should not become a retry storm against SendGrid or your own services.
4. Use the rehearsed fallback. For this dependency, apply bounded retries and shift traffic only to a pre-tested region, provider or degraded mode. Do not invent a new failover path during the outage.
5. Verify recovery end to end. A green SendGrid status is the start of validation: reconcile delayed writes, jobs and callbacks before restoring normal concurrency.

What breaks when SendGrid has issues

SendGrid sits in the cloud, data & ai layer. An incident can affect regional APIs, managed data paths, model calls, control planes and background jobs; the exact blast radius depends on the components, regions and features your production path uses. Treat the official component timeline as evidence, compare it with your own independent probes, and communicate the user-visible effect rather than saying the whole vendor is simply “down.”