NagMonReading the status summary
The heart of the Dashboard is the status summary: counts of hosts and services in each state, using the standard Nagios color language:
- Green — hosts Up, services OK. The number you want to be big.
- Yellow — services in Warning. Worth a look, not (yet) on fire.
- Red — hosts Down or Unreachable, services Critical. Deal with these first.
- Gray/neutral — Unknown and Pending states: checks that couldn't determine a state, or haven't run yet.
New to what these states actually mean on the Nagios side — including why a host can be Unreachable rather than Down? Our reference on Nagios host and service states covers the full model, including soft vs. hard states.
The header
The Dashboard header tells you what you're looking at: which server — or, with multiple servers enabled, which set of servers — is being monitored. It's also where per-server connection warnings appear. If one of your servers can't be reached, the header flags it explicitly while the rest of the Dashboard continues to show live data from the servers that are healthy. No silent gaps.
Current problems at a glance
Below the summary, the Dashboard surfaces current problems in priority order, so the most serious issues are at the top of the screen the moment the app opens. Tap any entry to go straight to the detail view for that host or service — current state, how long it's been in it, the last check time, and the plugin output — and from there you can acknowledge the problem or schedule downtime.
This is the core NagMon workflow: an email from Nagios tells you something broke; the Dashboard tells you how bad it is and where to start, faster than the web interface can render its first table on a phone.
Pull-to-refresh and the shared refresh cycle
NagMon uses a single shared refresh cycle: one fetch feeds all tabs. When the app refreshes — on its regular cycle, or when you pull down to refresh — the Dashboard, Hosts, Services, and Alerts tabs all update together from the same snapshot. You never see a Dashboard count that disagrees with the list behind it.
Pull-to-refresh is available whenever you want data right now — for example, right after acknowledging a problem or fixing the underlying issue, to confirm the state change has landed.