Mailgun status

How we check Mailgun

We watch api.mailgun.net 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 watch the API host your application posts messages to, and we pin the response an unauthenticated request receives rather than expecting a 2xx. The dashboard and the marketing site run separately and can be perfectly healthy while the sending API is refusing traffic, which is the failure that actually stops your email.

What is Mailgun?

Mailgun sends email on behalf of applications. Password resets, receipts, notification digests, invitations, and the long tail of transactional messages that a product emits are handed to its API and delivered without the sending team having to run a mail server, manage IP reputation, or negotiate with inbox providers directly. The service occupies the same position as a payment processor does for money: mostly invisible, and extremely noticeable when something goes wrong.

The distinction that matters most is between the API being available and email actually being delivered, because they fail in completely different ways and only one of them is an outage. When Mailgun accepts a message it has queued it, nothing more. Whether that message reaches an inbox depends on your domain's authentication records, the reputation of the sending IP, the content of the message, the recipient provider's filtering that week, and whether previous mail to that list bounced. Every one of those can go wrong while Mailgun's platform is entirely healthy, and none of them will ever appear on a status page. Teams regularly spend a morning looking for an outage that does not exist because a DNS change made during unrelated work broke a DKIM record.

Sending regions add a second source of confusion that is specific to Mailgun and a frequent cause of self-inflicted incidents. The US and EU regions are separate environments with separate hostnames and separate credentials, and a key from one will not authenticate against the other. The resulting 401 looks like a credential problem, which it is, but the cause is usually a configuration value copied between environments rather than anything anyone revoked. This is worth checking early, because the error message does not point at the region.

Inbound handling is the part most often forgotten. Applications that parse replies, run a support address, or process bounces through webhooks depend on delivery paths that are separate from outbound sending and can degrade on their own. An application whose outbound mail is flowing normally can be silently failing to receive anything, and because nothing errors, the discovery usually comes from a customer asking why their reply was ignored.

The practical response is to instrument the outcome rather than the service. Mailgun's event webhooks report delivery, bounces, complaints and unsubscribes per message, and a dashboard built on those detects a reputation problem days before it becomes the kind of failure anyone would think to look for on a status page.

Frequently asked questions

Is Mailgun down right now?

Check the board above; it reflects our own probes against Mailgun's API from all five of our regions, refreshed every couple of minutes and confirmed across two regions before this page would say down.

Mailgun accepted my message but it never arrived. Is that an outage?

Almost never. Acceptance means the message was queued, and everything that decides whether it lands in an inbox happens afterwards, including your domain's SPF, DKIM and DMARC records, the recipient's spam filtering, and your sending reputation. Mailgun's logs record what happened to each individual message, and a delivered, bounced or suppressed status there answers the question that no status page can.

Why did my emails suddenly start going to spam?

Because deliverability is a reputation problem rather than an availability problem, and it degrades gradually. A new sending domain with no history, a warm-up skipped, a spike in volume, a run of bounces from a stale list, or a DNS record edited during unrelated work will all push mail towards spam folders while every Mailgun system reports itself healthy. Check your authentication records and your bounce rate before looking for an outage.

Does a Mailgun incident affect inbound routing as well as sending?

Not necessarily. Sending, inbound routes, the logs API, and webhook delivery are separate paths, and it is normal for one to be degraded while the others work. If your application relies on inbound parsing or on delivery webhooks, those deserve their own monitoring rather than being assumed healthy because outbound mail is flowing.

I am getting 401 errors from the Mailgun API. Is Mailgun down?

No, a 401 means Mailgun answered you and rejected the credential. The usual causes are an API key that was rotated, a key scoped to a different domain than the one in the request, or a request sent to the US endpoint using a key from the EU region or the reverse. Region mismatches are easy to create and produce authentication errors that look nothing like their actual cause.