Resend status

How we check Resend

We watch api.resend.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 email-sending API returns to a request with no valid key rather than assuming any 2xx, since an unauthenticated request is correctly rejected on a healthy day and a monitor expecting a plain success code would misreport every one of those healthy days as downtime.

What is Resend?

Resend is a developer-focused transactional email API built around a simple idea: sending email from an application should feel like calling a modern API, not wiring up decade-old SMTP tooling. It handles the same core job as older, larger providers, getting an application's automated email, password resets, receipts, notifications, actually delivered to an inbox, but aimed at teams who want a small, well-documented API and React-based email templates rather than a sprawling marketing platform bolted onto a sending service.

Its outages carry the same quiet risk every transactional email provider does, and it is worth stating plainly rather than assuming it is obvious: email failures rarely announce themselves. A page failing to load produces an error a developer sees immediately. A failed email send, depending on how the calling code handles it, can simply vanish, no retry, no alert, nothing in your own logs that looks unusual unless you are specifically watching for failed API responses from Resend itself. The first sign is often a support message from a user who never got a password-reset link, arriving well after the incident that caused it has already ended.

Newer infrastructure providers, and Resend is a comparatively young company relative to the incumbents in this space, are also still in the part of their growth curve where request volume and infrastructure maturity change quickly, which is exactly the environment where independent, outside monitoring adds the most value: a provider's own status page reflects what they have chosen to post, updated on their own timeline, while this page reflects a fixed, external measurement taken on the same 2-minute schedule regardless of whether an internal incident has been declared yet.

If your application's emails through Resend are not arriving and the board above shows the API healthy, check your sending domain's authentication records and your account's rate limits before assuming an outage, both are common causes that produce an identical symptom from the outside.

Frequently asked questions

Is Resend down right now?

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

What happens to my emails if Resend goes down?

Transactional email your application tries to send during the incident either fails outright or queues, depending on whether your own integration retries a failed send. Many applications do not retry automatically, so an outage can mean emails that are genuinely never sent rather than merely delayed.

How would I even know Resend was down if I did not check this page?

Often you would not, at least not right away. Email failures rarely surface as a visible error in your own product, they surface later as a user asking why they never received a confirmation or reset link, by which point the connection to a specific incident is easy to miss.

Why check the API instead of the Resend website?

Because the marketing site staying up says nothing about whether the sending infrastructure your application actually calls is working. They are separate systems that can fail independently of each other.