Mango Go-Live Readiness and Maintenance Checklist

Overview

Going live with Mango by Radix IoT means transitioning from configuration and testing to production operation. This checklist ensures nothing is missed before launch and provides a maintenance schedule for ongoing reliability.

Pre-Go-Live Checklist

Database

• ☐ Database chosen on capability — H2 is Mango's shipped default and nothing in Mango disqualifies it from production. Move to MySQL or PostgreSQL if you need access to the database from outside Mango while it runs, replication, or backup and restore that do not depend on Mango
• ☐ Database tuned for Mango workload (buffer pool, connections)
• ☐ SQL database backup running — it ships enabled, so check its Last run — and a restore tested
• ☐ Mango NoSQL backup running (also enabled by default, keeping 365 versions) and a restore tested
• ☐ Backup storage has sufficient space
• ☐ Tested restore from backup on a staging system, including the Mango restart that Mango's own help requires after a SQL restore

JVM and Server

• ☐ JVM memory (-Xmx) sized for deployment (points × polling load)
• ☐ Mango runs as a service (auto-start on server boot)
• ☐ Server has adequate CPU, RAM, and disk for projected growth
• ☐ OS-level monitoring in place (disk space, CPU, RAM alerts)
• ☐ Time synchronization (NTP) configured on the server

Security

• ☐ Default admin password changed
• ☐ User accounts created with appropriate roles (no shared accounts)
• ☐ System permissions granted only where needed — most default to superadmin-only, but some start granted to every logged-in user through user — among them View events page, both watch-list permissions and the Core filestore read — so review those rows. Operators need View events page to see alarms at all. Administration pages are superadmin-only and cannot be delegated, whatever the permissions say
• ☐ HTTPS enabled (directly or via reverse proxy)
• ☐ Firewall rules in place (only necessary ports open)
• ☐ Audit trail recording — under Administration > System settings > Audit event alarm levels, no type is set to Do not log or Ignore, either of which stops that type being recorded. Retention is Purge audit events older than, one year by default

Data Sources and Points

• ☐ Point names standardized before configuring Platform Manager — device types find their points by exact, case-sensitive point name within the site and device tags, and KPIs by point name plus a deviceType tag of SITE or GLOBAL, and a point that does not match simply renders empty, with no error
• ☐ Roles and permissions designed before deployment (changing permissions after users are active disrupts workflows)
• ☐ All data sources enabled and polling successfully
• ☐ No communication errors in ma.log for 24+ hours
• ☐ Data points tagged consistently following the tagging strategy
• ☐ XIDs follow the naming convention
• ☐ Logging types set deliberately — All data stores every poll. New numeric points start on Interval (average, 1 minute) and other types on When point value changes
• ☐ Purge periods configured to balance retention vs storage
• ☐ Discard extreme values, with a Discard low limit and Discard high limit, set on numeric points that can read out of range

Events and Alarms

• ☐ Critical event detectors configured and active
• ☐ Email handlers tested — emails actually arrive
• ☐ Escalation set for safety-critical alarms — it is the Escalation mode of an Email handler, not a separate handler type
• ☐ Alarm levels appropriate (not everything is Critical) — and nothing that matters set to Do not log or Ignore, which stop an event being recorded at all
• ☐ Return-to-normal behavior set on each handler — Send inactive email on Email handlers, Inactive action on Set point handlers, Inactive process command on Process handlers

Dashboards and Reporting

• ☐ Operator dashboards built and tested
• ☐ Dashboard permissions set (operators see their dashboards)
• ☐ User home pages set to their primary dashboards
• ☐ Reports configured and scheduled
• ☐ Report email delivery tested

Monitoring

• ☐ Internal Data Source configured for system metrics
• ☐ System health dashboard built (JVM memory, thread count, poll performance)
• ☐ Health alerts configured (high memory, falling poll success percentage, low disk space)
• ☐ Baseline metrics recorded for normal operation

Documentation

• ☐ Role hierarchy documented
• ☐ Tagging taxonomy documented
• ☐ XID naming convention documented
• ☐ Backup and restore procedure documented and tested
• ☐ Contact information for Radix IoT support documented

Day-1 Post-Go-Live

1. Monitor ma.log for any new errors
2. Verify all data sources are polling successfully
3. Confirm scheduled reports generated and delivered
4. Check JVM memory usage trends (no steady increase = good)
5. Confirm backups ran on schedule
6. Have operators test their workflows and report issues

Ongoing Maintenance Schedule

Daily

• Review the alarm list — any unacknowledged alarms?
• Check the system health dashboard — any anomalies?
• Verify backups completed

Weekly

• Review ma.log for WARN and ERROR entries
• Check disk space (NoSQL database growth)
• Review trends of the Internal Data Source points (memory, thread count, poll duration) — the Internal metrics page itself shows only current values
• Verify scheduled reports generated correctly

Monthly

• Review user accounts — disable any no longer needed
• Review event detectors — any disabled or stale detectors?
• Check for Mango and module updates
• Review storage projections against actual usage

Quarterly

• Full security audit — review roles, permissions, and user accounts
• Review alarm statistics — any chattering alarms that need threshold adjustment?
• Review and tune polling intervals based on actual performance
• Update documentation for any changes made since last review
• Test full backup and restore on staging

Annually

• Review the entire deployment against original design goals
• Plan for upcoming year — capacity, new sites, new features
• Review and renew licenses — an expired license schedules an instance shutdown
• Major version upgrade evaluation

Emergency Procedures

Summary

A successful go-live requires systematic preparation across database, security, data collection, alarms, dashboards, and monitoring. Use this checklist to verify every category before launch. After go-live, follow the maintenance schedule to catch issues early and keep the system running reliably. The investment in pre-launch thoroughness pays dividends in operational stability.