Monitoring TP-Link Omada Controller with Vigilmon

The TP-Link Omada SDN Controller is the centralized brain for Omada-series access points, switches, and routers. When it's running, you get a unified dashboard for client counts, roaming, VLAN management, firmware upgrades, and alert notifications across your entire network. When it goes offline, your APs continue serving Wi-Fi — but you're flying blind. Device management stops, alerts stop, and any configuration changes become impossible until the controller recovers. Vigilmon keeps eyes on the Omada Controller's web interface, HTTPS endpoint, database-backed login page, and alert pipeline so you know the moment management capability is lost.

What You'll Set Up

HTTP uptime monitor for the Omada Controller management UI (port 8088)
HTTPS interface monitor with keyword validation (port 8043)
Database connectivity check via login page keyword monitoring
SSL certificate expiry alerts for the HTTPS management interface
Heartbeat monitoring for the Omada alert delivery pipeline

Prerequisites

Omada Controller running (Docker via mbentley/omada-controller or official TP-Link installer)
Controller web UI accessible over HTTP and/or HTTPS from a monitoring vantage point
A free Vigilmon account

Step 1: Monitor the Omada Controller HTTP Interface

The Omada Controller serves its management web UI on port 8088 (HTTP) by default. Add a Vigilmon HTTP monitor for baseline availability:

Log in to vigilmon.online and click Add Monitor.
Set Type to HTTP / HTTPS.
Enter the URL: http://your-omada-host:8088/
Set Check interval to 1 minute.
Set Expected HTTP status to 200.
Under Keyword check, enter Omada to validate the page title confirms it's the correct service.
Click Save.

The keyword check for Omada in the response confirms the Java application server is running and serving the correct interface — not a generic nginx placeholder or a different service occupying the port.

Step 2: Monitor the Omada Controller HTTPS Interface

The Omada Controller also serves HTTPS on port 8043. This is the recommended interface for remote access and is the endpoint affected by SSL certificate issues. Add a separate monitor for it:

Click Add Monitor → HTTP / HTTPS.
Enter the URL: https://your-omada-host:8043/
Set Check interval to 1 minute.
Set Expected HTTP status to 200.
Under Keyword check, enter Omada.
If using a self-signed certificate (common in home lab deployments), enable Ignore SSL errors — but still add a certificate expiry monitor in Step 4.
Click Save.

A 200 response with the Omada keyword on the HTTPS interface confirms both that TLS is configured correctly and that the Java application is serving behind it.

Step 3: Validate MongoDB Connectivity via Login Page

The Omada Controller login page requires MongoDB to render properly. If MongoDB is down or the controller cannot reach it, the login page shows an error — typically a 502/503 response or an error page instead of the login form, even if the Java process is still running.

The keyword check you configured in Steps 1 and 2 doubles as a MongoDB health signal:

HTTP 200 + keyword Omada present → Java app running, MongoDB connected, login page loading correctly.
HTTP 200 + keyword Omada absent → Java app is up but rendering an error page, which typically means MongoDB failure. Vigilmon alerts on keyword mismatch.
HTTP 502/503 → Java app crashed or not reachable.

No additional monitor is needed — the keyword check on the login page gives you a combined app + database health signal in a single probe.

If you want an explicit negative check, add a Keyword check (must be absent) for Database connection failed to catch MongoDB error messages that appear inline in the page rather than changing the HTTP status code.

Step 4: SSL Certificate Alerts for the HTTPS Interface

An expired SSL certificate on the Omada HTTPS management port blocks all admin access and management operations — including AP firmware upgrades, VLAN changes, and alert configuration. For organizations managing branch offices remotely over HTTPS, this is especially critical.

Open the HTTPS monitor created in Step 2.
Enable Monitor SSL certificate under the SSL section.
Set Alert when certificate expires in less than 30 days.
Click Save.

If you have a custom domain pointed at the controller (e.g. omada.yourdomain.com), add a monitor for that domain as well — the Omada-issued self-signed certificate and your domain certificate are separate and can expire independently.

Step 5: Heartbeat Monitoring for the Omada AP Sync Pipeline

The Omada Controller periodically syncs with registered APs, collecting metrics and delivering alerts when devices go offline. If the alerting pipeline breaks — because of a database write failure, a misconfigured webhook, or a broken email relay — you lose visibility into your network without knowing it.

Set up a Vigilmon cron heartbeat to verify the alert delivery pipeline end-to-end:

In Vigilmon, click Add Monitor → Cron Heartbeat.
Set the expected ping interval to 70 minutes.
Copy the heartbeat URL: https://vigilmon.online/heartbeat/YOUR_TOKEN

Option A: Omada webhook integration (if available)

Some Omada Controller versions expose a webhook or notification URL for device events. Configure Omada to POST to a small relay script that:

Receives the Omada notification.
Forwards the heartbeat ping to Vigilmon.

# Simple relay (e.g. in a cron job or triggered by Omada notification)
curl -s "https://vigilmon.online/heartbeat/YOUR_TOKEN"

Option B: Scheduled connectivity test

If your Omada version does not support webhooks, run a scheduled script that confirms AP sync is working by checking that the Omada UI is accessible with valid credentials and the AP list is non-empty:

#!/bin/bash
# Omada Controller health heartbeat
OMADA_URL="https://your-omada-host:8043"
HEARTBEAT_URL="https://vigilmon.online/heartbeat/YOUR_TOKEN"

# Verify login page loads with Omada keyword
RESPONSE=$(curl -sk -o /dev/null -w "%{http_code}" "${OMADA_URL}/")

if [ "$RESPONSE" = "200" ]; then
  curl -s "${HEARTBEAT_URL}"
fi

Add to cron for hourly execution:

0 * * * * /usr/local/bin/omada_heartbeat.sh

A missed heartbeat means either the Omada UI is unreachable or your sync/alerting check is failing — exactly the conditions under which your network management is degraded.

Step 6: Configure Alert Channels

Go to Alert Channels in Vigilmon and add email, Slack, or a webhook.
Set Consecutive failures before alert to 2 for the HTTP and HTTPS monitors — Java startup after a container restart can take 30–60 seconds and may cause a single-probe failure.
Set Consecutive failures before alert to 1 for the heartbeat monitor — a missed heartbeat always indicates a real problem with the sync pipeline.

Summary

| Monitor | Target | What It Catches | |---|---|---| | HTTP interface | http://host:8088/ + keyword Omada | Java app down, wrong service on port | | HTTPS interface | https://host:8043/ + keyword Omada | TLS failure, app down | | MongoDB signal | Keyword mismatch on login page | Database connectivity failure | | SSL certificate | HTTPS interface cert | Certificate expiry blocking admin access | | Cron heartbeat | Hourly AP sync check | Alert pipeline failure, silent management loss |

The Omada Controller is the management plane for your entire network — when it's unavailable, you don't lose connectivity, but you lose the ability to manage, monitor, and respond to network events. With Vigilmon watching the HTTP and HTTPS interfaces, validating MongoDB connectivity via the login page keyword, guarding the SSL certificate, and confirming the alert pipeline through heartbeat monitoring, you get the network management observability that Omada's own platform cannot provide for itself.