Is Hosted Mender down?

An upstream provider notified that they are experiencing elevated error accessing API on EU region. It's possible that the Mender devices are unable to pull artifacts and deployments might fail. We're monitoring the upstream incident status.

The upstream provider reported their incident is resolved.

We are currently investigating the root cause of the issue.

We found a possible root cause with the new intermediate certificate of https://eu.hosted.mender.io with a different size. A tested workaround is to increase the mbedTLS heap size in your application's prj.conf: CONFIG_MBEDTLS_HEAP_SIZE=98304.

This incident has been resolved by tuning the mbedTLS heap size.

We are currently investigating this issue.

The issue has been identified: there was an issue with the Redis and NATS deployments. A fix has been implemented and we're restarting the impaired services.

The affected services have been restarted and we're monitoring the results.

This incident has been resolved.

# Brief service disruption on Hosted Mender \(EU\) On June 24, between 12:04 and 12:09 UTC, some customers on our EU region experienced a short interruption. During this five minute window, devices may have had trouble connecting, and parts of the web interface and API may have returned errors. ## What happened While cleaning up a configuration issue, we removed an internal duplicated definition \(the same set of kubernetes manifests rendered twice from Kustomize\). Our automation interpreted this as a request to remove and reinitialize two background components that handle messaging and caching \(NATS and Redis\). They were rebuilt automatically, but for about five minutes they were unavailable, which caused the disruption. ## What we are doing about it The automation completed the reconciliation loop and redeployed the background components automatically. We verified that normal operation was restored and confirmed all services are healthy. We are changing how we make this type of change so that components are never removed before their replacement is ready. We apologize for the disruption.

Incident Summary - 2026-06-18 What happened On June 18, between 18:46 UTC and approximately 19:00 UTC, some users may have experienced intermittent connectivity issues or elevated error rates when accessing Mender services from the EU cluster. The incident was triggered by a scheduled maintenance job running on the infrastructure hosting our services. This job - responsible for cleaning up unused container images across cluster nodes - ran simultaneously on all nodes and consumed a significant amount of CPU resources. This created resource contention with the ingress controller pods responsible for routing incoming traffic, causing them to become temporarily unresponsive to health checks and restart repeatedly. The repeated restarts reduced the number of healthy ingress endpoints below the threshold required to serve traffic across all availability zones, leading to degraded routing and elevated error rates for most of the requests. Resolution The ingress controller stabilized once the image cleanup job completed. This job is a new managed feature coming from the recent Kubernetes upgrades, and since it’s not a critical feature, we suspended it. Additional safeguards have been put in place to prevent ingress controller pods from being affected by resource pressure from unrelated workloads. What we are doing The image cleanup job has been permanently suspended. CPU resource limits have been tightened on the ingress layer to isolate it from competing workloads. Node pool capacity is being expanded with larger instances to provide additional headroom. We apologize for the disruption.

We've identified a regression affecting users who access Mender with a custom role (rather than the built-in administrator role). As a result, we have rolled back to the previous version. When a user with a custom role attempts to list software when creating a deployment, the request is rejected with There was an error while listing software forbidden by role-based access control Only users assigned a custom role were affected. Users with the built-in admin role were not affected. We apologize sincerely for this issue.

We rolled back the affected version and we're monitoring the results

This incident has been resolved, the rollback worked and we'll apply the fix in the next release.