NagMonAdding a server in Settings
Beyond the first server you set up during onboarding, servers are managed in Settings. Each server entry has a display name, hostname, port, path, and credentials — the same fields described in Getting Started. The display name is yours to choose; it's what appears in server badges throughout the app, so short names like PROD or DC-EAST work well.
Custom ports
If your Nagios web interface listens on a non-standard port, set it in the Port field. As a shortcut, you can also append it to the hostname — nagios.example.com:8443 — and NagMon will pick it up.
Authentication
NagMon supports both Basic and Digest HTTP authentication out of the box. There's nothing to configure — the app negotiates whichever scheme your web server requests. Use the same username and password that works in your browser.
HTTPS options
- Enable HTTPS — use TLS for the connection. Recommended everywhere, and essential for servers reachable over the internet.
- Allow Self-Signed Certificate — accept a certificate that isn't signed by a trusted authority. This is reasonable for an internal server whose certificate you generated yourself and can vouch for. Avoid it for servers exposed to the internet: a trusted certificate is free with Let's Encrypt, and self-signed trust means the app cannot detect an impostor server.
Editing and removing servers
Open the server in Settings to change any of its details — renaming a server, updating credentials after a password change, or switching it from HTTP to HTTPS after hardening. Removing a server deletes its configuration from the device; because NagMon stores nothing anywhere else, that's the entire footprint.
Monitoring multiple servers at once
Every server has an enable/disable toggle. Disabled servers stay configured but aren't polled — useful for a lab you only care about occasionally.
When two or more servers are enabled, NagMon merges them into one view: the Dashboard counts, Hosts, Services, Alerts, and Outages tabs all show combined data. You triage your whole estate in one place instead of flipping between servers.
- Server badges — list items carry a badge showing which server they came from, so
web01on PROD is never confused withweb01on STAGING. Name collisions between servers are handled; identically named hosts remain distinct entries. - Per-server failure states — if one server becomes unreachable, the Dashboard header flags that server specifically while continuing to show live data from the others. One flaky VPN link doesn't blank out your whole view.
- Commands route correctly — acknowledgements and downtime always go to the server the host or service belongs to. See Taking Action.
Requirements and version notes
NagMon requires Nagios Core 4.x with the JSON CGIs (statusjson.cgi and friends), which ship by default with Core 4. Features degrade gracefully where the server can't support them: host groups, for example, need objectjson.cgi — on servers where it isn't available, the host-group view simply hides itself rather than erroring.
Curious what the JSON CGIs actually return? Our Nagios JSON API guide covers the endpoints with live examples you can run with curl.