SendGrid status

How we check SendGrid

We watch api.sendgrid.com from all five of our probe regions, every 2 minutes. A region that sees a failure does not make this page say "down" on its own: a second region has to agree first, the same confirmation rule every YoPingMe monitor uses.

We pin the exact response code the mail-send API returns to a request carrying no valid key rather than assuming any 2xx, since an unauthenticated request is correctly rejected on a healthy day and a monitor that does not expect that rejection would misreport every one of those healthy days as downtime.

What is SendGrid?

SendGrid is one of the larger transactional and marketing email providers, handling the mail that applications send automatically rather than the mail a person composes by hand: password resets, receipts, shipping notifications, sign-up confirmations, and marketing campaigns sent in bulk. An application calls SendGrid's API with a message and a recipient, and SendGrid handles the much harder problem of actually getting that message into an inbox rather than a spam folder, across every major mail provider's constantly shifting filtering rules.

An outage here has a specific kind of damage that is easy to underestimate. Most other services fail loudly, a page will not load, an API call throws an obvious error a developer sees immediately. Email often fails quietly. If your application does not check the result of a failed send, a SendGrid outage can mean emails that are simply never sent and never retried, not delayed, gone. A user who never received their password-reset link, or a customer who never got an order confirmation, has no visible sign that anything on your side went wrong, they just conclude your product did not work and each will need a separate support conversation before anyone connects the pattern back to a single incident.

The stakes vary a lot by what kind of email is affected. A delayed marketing campaign is a minor scheduling problem. A missed password-reset email during a real incident is a user who cannot get back into their account at the exact moment they are already frustrated. A missed transactional receipt can turn into a billing dispute weeks later when neither side has a record of it. None of these show up as a visible outage on your own site, which is exactly why watching the email provider directly, rather than waiting for a support ticket to surface the pattern, is worth doing.

If your application's emails are not going out and the board above shows SendGrid healthy, check your own sending domain's authentication records and account-level sending limits before assuming an outage, both are common, self-inflicted causes of exactly this symptom.

Frequently asked questions

Is SendGrid down right now?

Check the board above; it reflects our own probes against the mail-sending API, refreshed every couple of minutes from all five of our regions.

What happens to my emails if SendGrid goes down?

Transactional email your application tries to send during the incident, password resets, receipts, notifications, either fails outright or queues depending on how your own integration handles errors. Most applications do not retry failed sends automatically, so an outage can mean real, permanently lost emails rather than merely delayed ones.

Would I notice a SendGrid outage from my own dashboard?

Not always right away. If your code treats a failed send as a background task and does not surface the error loudly, an outage can go unnoticed until a customer asks why they never received a password-reset link.

Why do you check the API instead of SendGrid's marketing site?

Because the marketing site staying up says nothing about whether the mail-sending infrastructure your application actually depends on is working. The two are unrelated systems that can fail independently.