Common Mango Issues and Quick Fixes

Overview

This is a quick-reference guide to ten Mango by Radix IoT issues that come up regularly, and their fixes. Use it as your first stop when something goes wrong. For deeper investigation, see the Mango Troubleshooting Methodology: Step-by-Step Triage Guide article.

Prerequisites

• Mango 4.x or 5.x, with admin access for anything touching users, permissions, or system settings
• Access to ma.log on the Mango server
• The affected user account, or the ability to switch user from an admin account, so you can reproduce the symptom rather than infer it
• The exact error text or screenshot from the person reporting the problem

1. "I Can't See a Dashboard"

Symptom: Dashboard missing from menu or permission error when navigating to it.

Usual Cause: The dashboard's read permission does not include the user's role.

Fix:

1. Log in as a superadmin
2. Go to Platform management → Edit pages, choose the page, and open Edit page name and permissions
3. Add the user's role to View page
4. Save; have the user refresh their browser

Also check: Is the account enabled? Are correct roles assigned? View page is one link of four: the menu entry's View menu item can hide the page from the menu, a watch list the page uses needs View watch list, and the points need View point & value, or the page opens with no data.

2. "I See Too Much Data"

Symptom: User sees dashboards or data points they should not have access to.

Usual Cause: Overlapping roles or overly permissive read permissions (e.g., generic "user" role).

Fix:

1. Review the user's role assignments at Access management → Users
2. Remove overly broad roles
3. Replace generic roles with specific, scoped roles on objects
4. Check role inheritance for unintended access broadening

3. "Login Fails"

Symptom: Invalid credentials error or login page reloads.

Usual Cause: Incorrect password, a disabled account, an expired or administratively locked password, or authentication rate limiting.

Work through these four distinct causes:

1. Account disabled — check the account is Enabled in Access management → Users. A disabled user cannot authenticate at all
2. Password expired — if a password expiry policy is in force, the credentials are rejected as expired rather than wrong. Reset the password
3. Password administratively locked — an admin can lock a user's password, which is a deliberate action on that account, not something triggered by failed attempts. Reset the password to unlock it
4. Authentication rate limiting — repeated attempts from one IP address, or against one username, are throttled. Defaults allow a burst of 5 attempts then roughly 1 per minute, per IP and per username, so a user who has been guessing will keep failing for a while even once they get the password right. Wait it out, or review the rateLimit.authentication.* settings in mango.properties

Also check: If using LDAP, verify directory connectivity. Try an incognito/private window to rule out a stale session.

4. "Dashboard Widget Shows No Data"

Symptom: Dashboard loads but widgets are blank or show "no data."

Usual Cause: A permission is missing on one of the objects in the chain between the widget and the underlying data.

Fix: A widget typically reaches its data through more than one object, and every object in that path carries its own read permission. Check each of them:

1. Data point read permission — includes user's role?
2. Watch list or other intermediate object read permission — includes user's role? This is the layer people most often overlook, because the dashboard itself opens fine
3. Dashboard read permission — includes user's role?

Quick test: Log in as the affected user and navigate to the watch list directly. If it is empty, the problem is below the dashboard — at the watch list or the point permissions.

5. "Device Offline" or "Data Source Not Connecting"

Symptom: Data source error status, stale points, connection timeouts.

Fix — three diagnostic paths:

• Network: Ping the device. Check port is open. Ask about recent network changes (firewall, VLAN, switch).
• Credentials: Verify username/password. For SNMP, check community string. For BACnet, check device instance.
• Protocol: Verify IP/port. For Modbus, check unit ID. For BACnet, check BBMD. For HTTP, verify URL and headers.

6. "Points Not Updating"

Symptom: Data source is connected but specific points are stale.

Usual Cause: Point-level configuration issues.

Fix:

• Check register address, OID, or object identifier is correct
• Verify data type matches device (16-bit integer vs 32-bit float, etc.)
• Check tolerance settings — too high suppresses small changes
• Check retention/purge — data may be purged before you query it
• Verify tag consistency if using tags to organize points

7. "Email Alerts Not Sending"

Symptom: Event fires but no email arrives.

Usual Cause: SMTP not configured, or the SMTP server rejected Mango's credentials.

Fix:

1. Verify SMTP settings at Administration → System settings → Email settings
2. Click Send test email
3. For Gmail or Microsoft 365, use an app password rather than the account password. Mango sends over plain SMTP with optional authentication and TLS — there is no OAuth option for outgoing mail, so there is no token to refresh
4. Check event handler: enabled? correct event type? correct recipients?
5. Check ma.log for SMTP errors
6. Check recipient's spam/junk folder

8. "System Running Slow"

Symptom: Slow dashboards, sluggish UI, laggy data updates.

Investigate before changing anything:

1. Look at JVM memory as a signal, not a verdict: Mango exposes JVM maximum, used, and free memory monitors. High occupancy on its own does not mean the heap is too small — a healthy JVM routinely fills the heap and then collects. What distinguishes an undersized heap is sustained high usage after garbage collection, alongside rising GC time. Treat 80% as a prompt to look closer, not an instruction to resize
2. Correlate before resizing: Check CPU, GC pause time and frequency, thread and work queue depth, database query latency, polling load, and dashboard query volume. Enlarging the heap when the real constraint is a slow query or an over-polled data source hides the bottleneck and can lengthen GC pauses
3. Review polling frequencies: Reduce unnecessary high-frequency polling
4. Use rollups for wide time ranges: Dashboards querying weeks of raw data should request rollup aggregations instead, which cuts the number of values transferred and rendered
5. Reduce widget count: Dense dashboards issue more queries and render more, and splitting a crowded page into focused dashboards usually helps. How many requests a given page actually makes depends on the UI module and widget types, so measure it in your browser's network tab rather than assuming one call per widget
6. Check polling overlap: If poll duration > update period, increase the update period

Change one thing at a time and re-measure. If you do increase -Xmx, do it because post-GC usage stays high under representative load, not because a gauge read 80%.

9. "API Rate Limited"

Symptom: External apps receive HTTP 429 from the Mango REST API.

Fix:

• Check rate limit settings in mango.properties
• Increase limits if workload legitimately requires higher throughput
• Optimize API usage: WebSocket subscriptions for real-time data, bulk query endpoints, longer polling intervals

10. "Report Shows Gaps in Data"

Symptom: Reports have time periods with no data.

Usual Cause: The samples were never logged, were purged, or fall outside the queried range.

Fix — in this order:

• Verify logging config — ensure the point is not set to "Do not log", and check whether its logging type would produce samples during the quiet periods at all
• Check data source health — a source that was disconnected or disabled during the gap logged nothing to find
• Check retention — data may have been purged before the report ran. Purged history cannot be recovered by any query
• Verify the time range and timezone — mismatched timezones shift data into the wrong buckets, which reads as gaps at one end and duplicates at the other
• Then apply a rollup — once you have confirmed the samples exist, a rollup is the right way to summarise them for the report

Troubleshooting: When None of the Ten Match

If the symptom does not fit any scenario above, or a fix appeared to work and the problem returned, fall back to a structured pass rather than trying more quick fixes:

• Establish what changed. Configuration edits, module installs, upgrades, network changes, and certificate renewals are the usual triggers. Check the audit log for recent configuration changes
• Separate "cannot see" from "no data". A permission problem and an acquisition problem look identical to the person reporting it. Reproduce as an admin: if the admin sees data, it is permissions; if not, it is acquisition or retention
• Read ma.log around the first occurrence, not around the time it was reported. The first error in a cascade is usually the real one
• Check whether it is one object or many. One point, one dashboard, one user points at configuration; everything at once points at a service, resource, or connectivity fault
• Verify the clock and timezone on the Mango host and on the devices. Time skew produces symptoms across reporting, event timing, and retention that resemble half the scenarios above
• Reproduce deliberately. An intermittent fault you cannot trigger on demand is not fixed, however convincing the change looked

Then work the 8-Step Triage Framework from the start rather than continuing to guess.

Verification

Before closing any of these out, confirm the fix rather than the absence of the complaint:

• ☐ Reproduce the original symptom as the affected user, not as an admin — an admin sees past most permission problems
• ☐ For permission fixes, confirm the user can now reach the object and still cannot reach the things they should not
• ☐ For login fixes, confirm which of the four causes actually applied. If you reset a password and it worked, check whether the account was simply rate-limited and would have recovered anyway
• ☐ For connectivity fixes, confirm the data source is polling and points are receiving fresh timestamps, not just that the error cleared
• ☐ For performance changes, re-measure the metric you originally observed under representative load, and change one thing at a time
• ☐ For reporting gaps, confirm the underlying samples exist for the period before accepting a rolled-up report as correct
• ☐ Check ma.log for related errors that are still occurring quietly

When to Escalate to Radix Support

Contact Radix IoT support when:

• System crashes or restarts unexpectedly
• Database corruption or data integrity issues
• Module installation or upgrade failures
• Performance issues persist after tuning
• Licensing issues

Include with your support request:

• Mango version number
• Operating system and Java version
• The ma.log file (or relevant excerpts)
• Steps to reproduce the issue
• Screenshots of error messages
• Any recent changes made before the issue started

Summary

Most Mango issues fall into permissions, connectivity, configuration, or resources. This guide covers ten scenarios that come up regularly. Three corrections are worth carrying away from it: usernames are matched case-insensitively and there is no failed-login lockout, so diagnose login failures as disabled, expired, locked, or rate-limited rather than hunting for an unlock button; heap above 80% is a reason to investigate rather than an instruction to resize; and rollups summarise the data that exists rather than restoring history that was never logged or has been purged. When in doubt, follow the 8-Step Triage Framework and contact Radix IoT support when you need help.