UniFi Controller is the central management platform for UniFi Access Points, switches, and gateways.
In many enterprise and SMB environments, the stability of the UniFi Controller directly affects network visibility and wireless management.
If the controller goes down, administrators may lose the ability to manage devices, push configurations, or troubleshoot wireless issues.

Because of this, monitoring UniFi Controller is not optional—it is a critical operational requirement.
PRTG Network Monitor provides a flexible and lightweight way to monitor both the server hosting UniFi Controller and the controller service itself.
This guide demonstrates how to monitor UniFi Controller using PRTG step by step, focusing on reliability and real-world best practices.

Monitoring Strategy Overview

When monitoring UniFi Controller, the goal is not only to check if the server is online.
A proper monitoring strategy should answer the following questions:

• Is the server reachable?

• Are CPU, RAM, and disk resources healthy?

• Is the UniFi Controller service running?

• Will I be alerted before users notice problems?

PRTG allows you to answer all these questions using standard sensors without unnecessary overhead.

Step 1: Add UniFi Controller Host to PRTG

The first step is to add the server running UniFi Controller as a Device in PRTG.

• Use the server IP address or hostname

• Assign the device to an appropriate group (e.g., Linux Servers or Network Controllers)

• Configure credentials (SNMP or SSH depending on your setup)

This device will serve as the foundation for all UniFi-related sensors.

Step 2: Availability Monitoring

Ping v2 Sensor

The Ping v2 sensor is the most basic but essential sensor.

• Confirms the server is reachable

• Detects network outages or host failures

• Provides fast alerting when the controller becomes unreachable

This sensor should always be enabled and configured with short scanning intervals.

Step 3: Resource Monitoring

SNMP CPU Load

CPU monitoring helps detect performance bottlenecks caused by:

• Large numbers of managed APs

• Heavy client traffic

• Database load inside UniFi Controller

Recommended thresholds:

• Warning: > 80%

• Error: > 90%

SNMP Memory

Memory usage is critical for UniFi Controller stability.

• UniFi heavily relies on Java memory

• Memory pressure may cause controller crashes or slow UI response

Threshold recommendations:

• Warning: > 85%

• Error: > 95%

SNMP Disk Free

Disk usage must be monitored carefully, especially for:

• UniFi database files

• Backup storage

• Log files

Low disk space may prevent the controller from starting.

Recommended partitions:

• Root (/)

• Partition containing UniFi data

Step 4: Service-Level Monitoring (Highly Recommended)

Server availability alone does not guarantee that UniFi Controller is working.
The controller service may crash while the server remains online.

Depending on your OS:

• Use SSH Script / SSH Process sensors (with caution)

• Monitor controller port availability (e.g., 8443)

This ensures PRTG detects controller failures even if the OS is still running.

Step 5: Alerting and Threshold Tuning

Proper alert configuration is essential to avoid alert fatigue.

Best practices:

• Avoid overly aggressive thresholds

• Use warning states before error states

• Test alerts during maintenance windows

Well-tuned alerts ensure administrators act only on real issues.

Conclusion

Monitoring UniFi Controller using PRTG provides full visibility into both system health and controller availability.
By combining availability, resource, and service-level sensors, administrators can proactively detect issues before users are impacted.
This setup is suitable for enterprise networks, MSP environments, and advanced homelabs.