# Mailgun status

> Is Mailgun down? Live status for the Mailgun API, uptime history, and per-region response times from our own probes on three continents.

Published: 2026-08-28 | Canonical: https://yoping.me/status/mailgun

## 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.

The live board - the current verdict, 24-hour, 7-day, and 30-day uptime, and per-region response times - is on the HTML page at https://yoping.me/status/mailgun. Those numbers change too fast to repeat honestly in a static mirror, so where an answer below says "the board above", it means that page.

## 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.