Cluster performance metrics not shown for me

Marcin van de Ven 130 Reputation points
2026-06-15T12:00:30.9066667+00:00

Recently we've started using a Kubernetes Cluster for our applications. After we managed to get through the puzzling deployment, expensive VM-pools (than listed in the calculator), complicated downscaling, logging taking up more than 10GB of memory and a lot of networking issues, we got it running after several weeks of trial-and-error.

Some pods are sometimes still being unstable, crashing often due to the lack of memory, sometimes not even logging why. It all seem to be causing it by metrics being collected by Azure itself, Prometheus and Application Insights.

Currently it is kind of stable, however, I cannot see what the resource usage of each pod is. My colleagues, with exactly the same permissions according to IAM, can. I get the message "CPU/RAM limit is not set up" on the Workloads->Pods overview. In the Monitor module none of the graphs are working. I only get the message: "An unknown error occurred. Please try again or create a support ticket if needed."

I tried for several days, with even logging out of Azure Portal and shutting down my device multiple times. It is still not working and I cannot find what might be the cause. My two colleagues that are also responsible for managing the cluster, can view both the current usage in the Pods overview and the graphs in monitoring.

What else could the issue be, except for permissions? As subscription owner it is strange to me that non-owners have more data to work with than the owner. Especially when the permissions are set to be equal on the specific resource.

Azure Kubernetes Service
Azure Kubernetes Service

An Azure service that provides serverless Kubernetes, an integrated continuous integration and continuous delivery experience, and enterprise-grade security and governance.


Answer accepted by question author
Sina Salam 31,456 Reputation points Volunteer Moderator
2026-06-15T14:53:26.1933333+00:00

Hello Marcin van de Ven,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that Cluster performance metrics not shown for you in the Portal.

Regarding your explanations. The core problem is not AKS workload instability first, it is a user-specific monitoring data access/rendering issue, plus a separate workload configuration issue shown by “CPU/RAM limit is not set up.”

To fix the issue, grant yourself access to all monitoring data planes used by AKS Monitor/Insights, not only the AKS resource IAM blade.

  1. Grant the affected user Monitoring Reader or Monitoring Contributor on the AKS cluster, the Log Analytics workspace, the Azure Monitor workspace used by Managed Prometheus, and related Data Collection Rules. - https://learn.microsoft.com/en-us/azure/azure-monitor/containers/kubernetes-monitoring-enable, https://learn.microsoft.com/en-us/azure/azure-monitor/metrics/metrics-troubleshoot
  2. Grant Kubernetes API read access separately if the cluster uses Microsoft Entra/Azure RBAC for Kubernetes authorization, for example Azure Kubernetes Service RBAC Reader at cluster or namespace scope. - https://docs.azure.cn/en-us/aks/concepts-identity, https://learn.microsoft.com/en-us/azure/aks/entra-id-authorization
  3. Fix the “CPU/RAM limit is not set up” message by adding resource requests and limits to the pod/container manifests. - https://learn.microsoft.com/en-us/azure/aks/developer-best-practices-resource-management, not just by the permission. - https://learn.microsoft.com/en-us/azure/aks/kubernetes-portal
  4. If the Monitor graphs still show “An unknown error occurred,” check browser/ad-blocking and Azure Monitor workspace networking/private-link access. - https://learn.microsoft.com/en-us/azure/azure-monitor/metrics/metrics-troubleshoot, https://docs.azure.cn/en-us/azure-monitor/containers/container-insights-experience-v2

Therefore, even if AKS resource IAM appears equal. AKS pod/resource views depend on a combination of AKS resource IAM, Kubernetes API authorization, Log Analytics workspace access, Azure Monitor workspace/Prometheus access, and sometimes browser/network access to Monitor endpoints. You will mneed to have complete effective access to the monitoring data plane used by the AKS portal experience. Fix those permissions directly, then separately add CPU/memory requests and limits to the workloads. This restores the portal metrics and explains the “CPU/RAM limit is not set up” message.

I hope this is helpful! Do not hesitate to let me know if you have any other questions, steps or clarifications.


Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

Was this answer helpful?

1 person found this answer helpful.

1 additional answer

Sort by: Most helpful
  1. Anonymous
    2026-06-15T15:37:45.58+00:00

    Hello Marcin,

    Thank you for reaching out Q/A and sharing the detailed explanation

    Based on the symptoms you described, this is most likely not a pure RBAC/Owner permission issue, but rather a combination of AKS monitoring data access, live metrics limitations, or workspace-level access differences in Azure Kubernetes Service.

    1. Private cluster / Live metrics limitation

    If your AKS cluster is configured as a private cluster, Azure Portal “live metrics” and some pod-level monitoring views may not function correctly.

    This is because live metrics requires the browser-based proxy to reach the Kubernetes API server. In private clusters, or environments with restricted network paths (NSGs, firewalls, UDRs), this connectivity may be blocked.

    Microsoft documentation notes that:

    • Private clusters are not fully supported for live metrics in all scenarios
    • The portal relies on proxy-based access to the Kubernetes API
    • Network restrictions can prevent pod-level metric visibility

    Reference: AKS private cluster limitations for monitoring/live metrics

    1. Metrics Server / Pod resource metrics availability

    The message “CPU/RAM limit is not set up” typically indicates that Kubernetes cannot determine resource requests/limits for workloads, or metrics are not being served correctly.

    Common causes include:

    • Missing resources.requests/limits in pod specifications
    • Metrics Server not functioning properly in the cluster
    • Delayed or broken metrics ingestion pipeline

    When Metrics Server is unhealthy, commands like kubectl top pod may also fail or return incomplete results.

    Reference: Kubernetes metrics and AKS monitoring reference

    Metrics collected by Container insights

    3)Log Analytics / Azure Monitor Workspace Access Mismatch

    Even if AKS IAM permissions are the same for all users, monitoring data is ultimately controlled through the connected Log Analytics workspace. If you are able to access the cluster but cannot view graphs while others can, a common reason is that your account may not have sufficient permissions on the workspace itself, such as Log Analytics Reader or Monitoring Reader access.

    In some cases, the cluster may also be sending telemetry to a workspace that you do not have full read access to, which results in incomplete or failed queries in Azure Monitor. This typically leads to errors like “Unknown error occurred” in the monitoring blade or missing container insights data. Microsoft documentation on Container Insights highlights that workspace-level access is required to properly query and visualize monitoring data.

    Reference: https://learn.microsoft.com/en-us/azure/azure-monitor/containers/kubernetes-monitoring-overview

    1. Network, Session, and Browser Factors

    In some cases, the issue may also be related to session or network differences. Conditional Access policies, VPN routes, proxy tools, or browser cache can sometimes block or disrupt Azure Monitor queries for a specific user session while working normally for others.

    Was this answer helpful?

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.