All status pages

Mailgun statusLiveFetched seconds agoSource: status.mailgun.com

Is Mailgun down?

Live status check · All systems operational

NO

Live status pulled from status.mailgun.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 Mailgun status

Mailgun is one of the older transactional email APIs, now owned by Sinch, and covers sending, inbound parsing, and email validation. Incidents are usually scoped to one component (outbound, inbound, or webhook events) and to one region (US or EU) rather than the whole platform.

Components and surfaces that can break

  • Surface 01

    Outbound Sending API (POST /v3/{domain}/messages) and SMTP relay.

  • Surface 02

    Inbound webhook routing (Mailgun Routes) and MIME parsing.

  • Surface 03

    Event webhooks (delivered, opened, bounced), validation API, and the dashboard.

Recent Mailgun incidents

Mailgun 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 Mailgun is actually down

  1. Queue sends client-side and retry yourself

    Mailgun does not retry your POST /messages call for you. If the API returns 5xx, the message was never accepted. Persist the send in your DB or job queue, mark the user request as 'will email shortly', and replay it once Mailgun recovers.

  2. Check the right region and the right component

    Mailgun runs separate US and EU instances, and the status page splits sending, receiving, and webhooks per region. An incident on EU receiving does not stop US outbound. Confirm which region your domain is in (api.mailgun.net vs api.eu.mailgun.net) before assuming you're affected.

  3. Webhook delivery retries; inbound recovers on its own

    Event webhooks (delivered, bounced, opened) retry from the Mailgun side on a backoff, so missed events usually arrive once your endpoint and Mailgun are both healthy. Inbound Routes also re-process queued messages after recovery, so you generally don't lose mail that hit Mailgun during the blip.

Keep firing through the incident

Schedule your own Mailgun health check with Crontap

Scheduled email digests, daily transactional batches, and weekly reports. Crontap fires the endpoint that builds the digest and calls Mailgun; retries on 5xx so a transient Mailgun blip doesn't kill the 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.

Mailgun status: FAQ

Where can I see the official Mailgun status?
status.mailgun.com publishes component status for sending, receiving, validation, webhooks, and the dashboard, split between the US and EU regions. The history page lists past incidents with timestamps and post-mortems.
Does Mailgun retry sends that failed during an outage?
No. POST /v3/{domain}/messages is what accepts the send into Mailgun's queue. If that request returned 5xx, the message never entered the queue, so Mailgun has nothing to retry. You need to replay the request from your side once the API is healthy.
What about EU vs US region issues?
Mailgun runs separate US (api.mailgun.net) and EU (api.eu.mailgun.net) infrastructures with independent status. An incident in one region does not affect the other, so check both the component and the region on the status page before you change anything in your app.