Mailgun's EU region saw inbound email routing delays for 46 minutes on 30 September 2026. Mailgun's own status page identifies this as a fault on their side, not yours.
Started
09:16 UTC
Duration
Lasted 46m
Source
IsDown
Next time
Mailgun is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
Affected components: Inbound email processing
What happened?
Mailgun logged one incident on this day, starting at 09:16 UTC and lasting 46 minutes, affecting inbound email processing. The incident was titled "Route delays in EU Region", which tells you this was confined to EU-based routing rather than a global failure. Mailgun posted four updates over the course of the incident. At 09:16 they opened with a standard investigating message. By 09:38 they said the issue had been identified and a fix was being implemented, a gap of 22 minutes between first acknowledgement and diagnosis. Ten minutes later, at 09:48, they moved to monitoring, saying a fix had been implemented. The incident was marked resolved at 09:58, closing the window at 46 minutes total. No user reports were filed during the window on the record, and no post-mortem has been published explaining what caused the routing delay. Mailgun's status page gives you the sequence of actions taken but not the underlying cause, so you are left with the timeline alone. Over the past 90 days Mailgun has logged 11 incidents with a median duration of 1 hour 14 minutes, which makes this one shorter than their recent typical incident. Across all time Mailgun has recorded 203 incidents at a rate of about 2.6 per month.
Learning
This incident sat inside Mailgun's inbound processing layer, specifically routing in the EU region, which is a part of their infrastructure you cannot see or probe directly from outside. UptimeRobot's own 30-day figures show 4 incidents detected independently, all resolved, with a median duration of 41 minutes, a separate measure built from checking Mailgun's endpoints rather than relying on their self-reported status. If your own monitoring stayed green through this window, that is not a contradiction: an external check against the API endpoint can succeed even while a specific regional routing path inside the provider is delayed, because the two are testing different things. This is the general shape of a provider-side partial outage: the component that fails is often narrower than the whole service, and it fails in a place your own uptime checks never touch. When email appears delayed or missing on your end during a window like this, the first question is whether the fault is yours or theirs, and a report like this one answers it without guesswork. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
