Azure IoT Central Dashboard UI Issues – Dashboard Selector and Last Known Value Visual Editing

Hello @twebber_sb

Did you get any chance to review the response.

Thankyou!

Hi @Anshika Varshney ,

Thank you for your response.

I have collected the requested information below. Please note that the attached logs and HAR files have been sanitised to remove potentially sensitive identifiers before posting publicly.

Requested Information

Browser Console Logs

Attached: domain.azureiotcentral.com-1781737800003.log

HAR / Network Trace

Attached: domain.azureiotcentral.com.trimmed.har.log

The HAR has been reduced to fit the Microsoft Q&A attachment size limit. I have retained the failing Azure IoT Central requests and associated error responses. If a complete HAR is required, I can provide it through an alternative channel.

Azure Region

Australia East

Scope of Impact

The issue appears to affect all client-facing dashboards containing Last Known Value (LKV) visuals that we have examined so far.

The issue has been reproduced across:

Multiple organisations/tenants

Multiple user permission levels

Microsoft Edge and Google Chrome

Approximate Time Observed (UTC)

The attached logs were captured on approximately:

2026-06-17 23:42 UTC

However, the issue has been consistently observable over the past several days. The issue was first reported by users on 9th June.

Additional Observations

The issue persists in Incognito mode. The attached logs were taken on a browser with minimal extensions (only Google Docs Offline)

The information above relates specifically to the Last Known Value visual issue, which is readily reproducible.

The dashboard selector issue ("Go to dashboard catalog" workaround) is less consistently reproducible, but appears more likely to occur during browser sessions that have remained open for longer periods.

In addition, there are several other UI behaviours that may be related and could indicate a broader frontend rendering or data retrieval issue:

Masthead logo is not loaded

Visible in the attached browser console logs.

  The application continues to function, but the logo image request fails.
  

1. Device hover card data is not loaded

When hovering over a device hyperlink within an LKV visual, the expected device information popup does not appear.

• Attached: domain.azureiotcentral.com.har-hover.har.log

Behaviour of Developer Tools

One of the more unusual aspects of the issue is that opening the browser Developer Tools frequently causes the affected UI elements to begin rendering correctly.

This behaviour has made troubleshooting somewhat difficult, as enabling observability often alters the symptoms being investigated.

Please let me know if there are any additional diagnostics, traces, or browser captures that would be useful.

Hi @twebber_sb

Thank you for providing the detailed diagnostics, logs, HAR traces, and additional observations.

Based on the information you've shared, the issue appears to extend beyond a single dashboard component and may indicate a broader frontend rendering or data retrieval problem in Azure IoT Central, especially considering:

• The issue is reproducible across multiple tenants and user roles.
• It occurs in both Edge and Chrome.
• It persists in Incognito mode.
• Multiple UI elements are affected (LKV visuals, dashboard selector, device hover cards, and masthead logo).
• Opening Developer Tools often causes the UI to render correctly, which may indicate a client-side timing, caching, or asynchronous loading issue.

Additional troubleshooting steps

Could you please try the following and share the results.

1. Create a brand-new dashboard
   • Create a new dashboard containing only a single Last Known Value visual.
   • Verify whether the issue occurs on newly created visuals or only on existing ones.
2. Test with a new device template
   • Create a test LKV visual using a different device template and telemetry field.
   • This helps determine whether the issue is tied to a specific device model or dashboard configuration.
3. Capture failed network requests
   • In the browser Network tab, filter for:
   • api
   • dashboard
   • device
   • visual
   • Identify any requests returning 4xx or 5xx errors and share the response details (sanitized if needed).
4. Disable browser caching
   • Open Developer Tools → Network tab → Enable Disable cache
   • Refresh the page and check whether the behavior changes.
5. Compare successful vs failed sessions
   • Since opening Developer Tools often makes the issue disappear, if possible capture:
   • One HAR when the issue is occurring
   • One HAR after Developer Tools causes the page to render correctly
   • Comparing the two traces may reveal missing or delayed requests.
6. Verify whether all affected users are in Australia East
   • If possible, confirm whether users in other IoT Central applications hosted in different regions observe similar behavior.

At this point, the most valuable data would be:

• Response details for failing API calls (4xx/5xx)
• Whether the issue affects newly created dashboards/visuals
• A comparison between failing and successful network traces
• Any JavaScript errors or warnings related to dashboard rendering, device lookup, or visual configuration

Do let me know if you have any further queries.

Thankyou!

Finally I've found someone else having this issue.

I have exactly the same issue as the OPs experiences. This seems to be an Azure IoT Central issue as I am in Canada and my data is in Canada Central. It has basically made my dashboards unusable. I created a new dashboard and the same issue occurs when I start to add multiple LKV tiles. Problem started after four tiles and no tile is editable with 6LKV tiles on the dashboard.

Dashboards cannot be edited and dashboards are slow to render with some LKV tiles just having an indefinite spinning circle. Opening the developer tools trick to edit the tiles doesn't work for me.

Hi @Anshika Varshney ,

Thank you for the additional troubleshooting suggestions. I have completed the requested testing and attached the resulting HAR traces (sanitised where required).

1. New Dashboard Testing

I created two new dashboards to determine whether the issue was limited to existing dashboards and visuals.

Initial testing

Created a new private dashboard containing a single Last Known Value (LKV) visual.

Saved, navigated away, and returned to edit the visual.

No issue observed.

I then repeated the same process with:

A new organisation dashboard.

A single LKV visual.

Again, the visual initially behaved as expected.

Additional testing I progressively added more content to the dashboard:

Map (Property) visual.

Number of Devices (Count) visual.

Multiple additional LKV visuals.

As complexity increased, the behaviour became less reliable.

Notable observations:

Device group lists sometimes took an unusually long time to populate.

Configuration dialogs occasionally remained in a loading state for several minutes before eventually resolving.

• After extended waiting periods, I observed several IoTCentral-PROD403 responses before content was eventually served (HAR Attached in later section).

Following these events, I was able to reproduce behaviour similar to the original issue on the newly created dashboard.

2. Existing vs New Visuals

My initial observation was that newly created LKV visuals appeared to behave correctly while existing visuals did not.

However, after additional testing, I was able to observe similar behaviour on newly created dashboards once multiple LKV visuals and other dashboard components had been added.

Based on this testing, the issue does not appear to be limited exclusively to existing dashboards or existing visuals.

3. Failed Network Requests

A HAR trace containing observed 403 responses is attached. (domain.azureiotcentral.com.har-403.har.log)

Additional observations:

Dashboard selector

• When the dashboard dropdown fails to populate, the associated requests appear to be GraphQL requests. Request payload: graphql.log.txt

I have not observed these requests fail with a network error or timeout.

The requests either:

Eventually resolve and populate the dropdown, or

  Are cancelled if the dropdown is closed before completion.
  

LKV configuration dialogs

• When LKV device group options fail to populate, the associated requests appear to be REST API GET requests against deviceGroup endpoints.

I have not observed these requests fail with a network error or timeout.

Similar to the dashboard selector behaviour, the requests either:

Eventually resolve after a significant delay, or

  Are cancelled if the dialog is closed.
  

This has led me to suspect that the primary symptom may be extremely delayed data retrieval rather than outright request failure.

4. Browser Cache Disabled

I repeated testing with browser caching disabled via Developer Tools → Network → Disable Cache.

No meaningful change in behaviour was observed.

5. Successful vs Failed Sessions

I have attached:

• A HAR trace captured while the issue was occurring. (fetch to azureiotcentral.com/_web/deviceGroup/<appID>?%24orderBy=name%20asc&%24top=100 did not resolve) domain.azureiotcentral.com.har-lkv_fail.har.log
• A HAR trace captured during a successful session. domain.azureiotcentral.com.har-lkv_ok.har.log
• A HAR trace from a different user account with fewer permissions. domain.azureiotcentral.com.har-lkv_ok_orguser.har.log

Observations:

The lower-permission user experienced similar symptoms.

Requests appeared somewhat more reliable and generally completed sooner.

However, data retrieval was still frequently slow enough to negatively impact usability.

6. Regional Comparison

My IoT Central application is hosted in Australia East.

In addition, comments from another user in this thread indicate that similar behaviour has been observed in Canada Central, which may suggest the issue is not isolated to a single region.

Additional Observation

During one test session, I briefly observed device groups appearing in an organisation where they should not have been visible.

I was unable to reproduce this behaviour and therefore cannot determine whether it was related to the issue under investigation or an isolated anomaly.

Please let me know if there are any additional diagnostics or traces that would be useful.