Resend statusLiveFetched seconds agoSource: resend-status.com
Is Resend down?
Live status check · All systems operational
Live status pulled from resend-status.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 Resend status
Resend is the modern transactional email API used by a lot of newer React/Next.js apps. Incidents typically affect either the API (sending) or the inbound/webhook plane (receiving + delivery events); delivery to mailbox providers is usually unaffected by API blips.
Components and surfaces that can break
- Surface 01
Send API (POST /emails) and the React Email integration.
- Surface 02
Webhooks (delivery, bounce, complaint events).
- Surface 03
Dashboard, audiences, broadcast scheduler.
Recent Resend incidents
Resend 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 Resend is actually down
Queue sends client-side, don't drop them
If Resend's API is returning 5xx, your app shouldn't lose the user-facing action. Queue the send in your DB or a job queue, mark the user request as 'will email shortly', and retry the send once Resend recovers.
Check whether it's send or webhooks
Send and webhook delivery are separate components. If only webhooks are degraded, your outbound mail is still going out — you're just temporarily blind to delivery events. Resend retries webhook deliveries automatically.
Important transactional? Verify with the Resend dashboard
After the incident clears, spot-check the dashboard to confirm the messages sent during the brownout actually delivered. The /emails endpoint may have returned a 200 but the message could have been deferred.
Keep firing through the incident
Schedule your own Resend health check with Crontap
Scheduled email digests (weekly reports, daily summaries, monthly invoices) are HTTP cron against your own /jobs/send-digest endpoint that wraps Resend. Crontap fires the endpoint on schedule, retries on 5xx, and emails you (separately) if the digest job itself fails.
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
Resend status: FAQ
- Where do I check Resend status?
- status.resend.com publishes component status for the API, webhooks, dashboard, and SMTP. The history page has incident summaries.
- Will Resend retry sends that failed during an outage?
- No. The POST /emails call is what triggers the send — if it returned 5xx, the message was never accepted. You need to retry the request from your side once Resend is healthy again.
- How do I make a scheduled email digest reliable?
- Schedule a Crontap job against your digest endpoint at the cadence you want. Inside the endpoint, build the digest, call Resend, and return 5xx if Resend fails. Crontap retries 5xx on a backoff, so a transient Resend blip doesn't kill the run.