Top 50 Nagios Interview Questions (2026)

Nagios is an open source monitoring system. It watches hosts, services, applications, and network devices, checks whether they're healthy on a schedule you define, and alerts the right people the moment something breaks or recovers. The engine is Nagios Core, and the actual checks are done by small external programs called plugins that report back a status.

The problem it solves is knowing about failures before your users tell you. Instead of someone noticing a dead disk or a down website by accident, Nagios runs checks on a schedule and pages or emails on-call staff the moment a check fails. It's a way of turning silent outages into loud, actionable alerts.

Nagios Core is the free, open source engine: the scheduler that runs checks, the plugin execution, the text config files, and a basic web interface. It's what most people mean by 'Nagios' and where all the fundamentals live, so it's what the concepts in an interview almost always assume.

Nagios XI is the commercial product built on top of Core. It adds a friendlier web UI for configuration, dashboards, reporting, advanced graphing, and vendor support. Underneath, XI is still check-based Nagios, so the concepts you learn on Core carry straight over.

A plugin is a small standalone program that performs the actual check. Nagios Core doesn't ping a host or query a port itself; it runs a plugin like check_ping or check_http, and that plugin does the real work and reports back. Nagios ships a standard plugin set, and the community has written hundreds more for almost anything you'd want to monitor.

Every plugin follows the same contract: it returns an exit code (0 OK, 1 WARNING, 2 CRITICAL, 3 UNKNOWN) and a line of text describing the result. Because the contract is fixed, you can write your own plugin in any language, and Nagios treats it exactly like the built-in ones.

The exit code a plugin returns is how it reports state, and it's the whole contract between a plugin and Nagios. Zero means OK, one means WARNING, two means CRITICAL, and three means UNKNOWN. Nagios reads that single number to set the host or service state and to decide whether anything needs to happen next.

UNKNOWN is the one people forget: it means the check itself couldn't run properly (bad arguments, the plugin errored, a timeout), not that the thing being monitored is down. Treating UNKNOWN as CRITICAL is a mistake, because the fix is usually your check, not the target.

An active check is one Nagios schedules and runs itself: at the configured interval it executes the plugin and reads the result. Most checks are active, and Nagios is fully in control of when they happen and how often. This is the default model you'll set up for almost everything you monitor directly.

A passive check is a result submitted to Nagios from outside, rather than one Nagios initiated. An external process runs a check and pushes the outcome in (commonly via NSCA or the external command file), and Nagios just processes what it's given. Passive checks fit things that happen on their own schedule, like a batch job reporting its own success.

A host is a physical or virtual machine or device you monitor: a server, a router, a switch. A service is a specific thing you check on that host: HTTP on port 80, free disk space, a running process, CPU load.

One host usually has many services attached to it. The distinction matters because Nagios treats them differently: a host going down can suppress its service alerts (no point paging about a website on a server that's completely offline), which is what host and service dependencies manage.

A host can be UP, DOWN, or UNREACHABLE. UP means it's responding, and DOWN means the host check failed. UNREACHABLE means Nagios can't even get to it because a parent host or network device sitting between Nagios and this host is itself down, so the host's real state is unknown rather than confirmed dead.

UNREACHABLE is what keeps alert storms in check. If a core router dies, you don't want a page for every one of the fifty servers behind it. By defining parent relationships, Nagios marks those servers UNREACHABLE instead of DOWN and can suppress their notifications, pointing you at the real culprit.

A service can be OK, WARNING, CRITICAL, or UNKNOWN, matching the four plugin exit codes one to one. OK is healthy, WARNING is degraded but not down, CRITICAL is failing and needs action, and UNKNOWN means the check itself couldn't produce a clear result. Those four states are what every service check ultimately reports back to Nagios.

WARNING and CRITICAL usually come from thresholds you set. For a disk check you might warn at 80 percent full and go critical at 90, so the plugin returns 1 or 2 depending on how bad it is. Setting those thresholds sensibly is what makes alerts meaningful instead of noisy.

You define a host in a text config file as an object with directives: a host_name that identifies it, an address (IP or DNS name), a check_command that tests whether it's alive, and usually a template it inherits from via the use directive. Each directive tells Nagios one thing it needs to know to monitor that machine.

Templates matter here. Instead of repeating the same settings on every host, you define a generic-host template once and have each host inherit it, overriding only what's different. That inheritance is how a real Nagios config stays manageable as hosts multiply.

A service object names the check with service_description, points at the host or hostgroup it runs on via host_name or hostgroup_name, and sets a check_command along with its warning and critical thresholds. Like hosts, services usually inherit shared settings from a template so you're not repeating the same lines on every one.

The link is the host_name directive: it ties the service to the machine it lives on. Attach the same service to a hostgroup and Nagios applies it to every host in that group, which is how you say 'check disk on all Linux servers' without writing it fifty times.

A command object gives a name to a specific plugin invocation. You define it once with a command_line that points at the plugin binary and lists its arguments, then reference that command by name from any host or service that needs it. This keeps the plugin path and call in one place instead of scattered across every check.

Arguments are passed positionally as $ARG1$, $ARG2$ and so on, so one command like check_http can take different thresholds each time it's used. This indirection keeps your host and service definitions clean and your plugin paths in one place.

Macros are variables Nagios substitutes into command lines and notification messages at runtime, right before it runs them. $HOSTADDRESS$ becomes the host's IP, $SERVICESTATE$ becomes OK or CRITICAL, $HOSTNAME$ becomes the host name, and so on. They're the reason one command definition can work for hundreds of different hosts without any hardcoded values.

They're what make definitions reusable. Because a command references $HOSTADDRESS$ instead of a hardcoded IP, the same check works for every host. In notification commands, macros build the alert message: which host, which service, what state, at what time.

When a host or service reaches a HARD problem state, Nagios sends a notification by running a notification command, most often an email, but it can be SMS, a Slack webhook, or a paging tool. Contacts and contact groups say who gets told.

Several settings gate it: notification_period limits when alerts can go out, notification_interval controls repeat reminders, and notification_options picks which state changes notify (warning, critical, recovery). Recoveries matter too: an OK-again notification tells people the problem cleared.

NRPE stands for Nagios Remote Plugin Executor. It lets the Nagios server run plugins on a remote Linux or Unix host and get the result back, so you can check things that are only visible locally on that machine, like free disk space or CPU load. Without something like NRPE, the server could only see a remote host from the outside.

It's needed because a check like disk space or CPU load can't be measured from across the network; you have to run it on the target. NRPE has two parts: a daemon on the remote host that runs the local plugins, and the check_nrpe plugin on the Nagios server that asks it to.

For basic reachability you just ping it, no agent needed on the Windows box at all. For local metrics like disk, CPU, memory, and Windows services, you install an agent on the machine because NRPE is aimed at Linux and Unix rather than Windows. NSClient++ is the usual agent people install for this job.

Once NSClient++ is running, the Nagios server queries it, historically with check_nt, or in NRPE-compatible mode, to pull those local metrics. So the pattern is the same as Linux (a remote agent runs local checks), just with a Windows-native agent.

check_interval is how often Nagios runs the check while the state is OK and stable, for example every 5 minutes. retry_interval is how often it rechecks once a check has failed and the state is SOFT, usually shorter so it confirms a real problem quickly.

The idea is to recheck fast when something looks wrong. A single failed check might be a blip, so Nagios switches to the retry interval and rechecks up to max_check_attempts times before deciding the problem is real (HARD) and notifying.

Monitoring turns silent failures into alerts. Without it, you find out a server's disk filled up or a site went down when a customer complains, which is the worst possible moment. With it, you get told the instant a check fails and can fix things before most users notice.

Beyond alerting, it gives you history and evidence: what was up when, how often something flaps, whether a fix actually held. That record is what you use during an incident and afterward to stop it happening again.

The top-level file is nagios.cfg, the main config Nagios reads on startup. It sets global behavior and, more importantly, points at the object config files (via cfg_file and cfg_dir) where your hosts, services, commands, and contacts actually live. Then there's resource.cfg, which holds macros like $USER1$ (the plugin directory) and is kept readable only by Nagios because it can store secrets.

Your object definitions are usually split across many files under a conf.d or objects directory, grouped by type or by environment. Keeping them modular is what makes a growing config navigable instead of one giant unreadable file.

A host check decides whether the machine itself is considered UP, DOWN, or UNREACHABLE, and Nagios treats it specially. To save load, Nagios often runs host checks on demand, only when a service on that host fails, rather than constantly, then uses the result to decide whether to bother alerting on the services.

A ping service check is just a regular service using check_ping, watching latency and packet loss as an ordinary OK/WARNING/CRITICAL service on its own schedule. So one answers 'is this box alive at all', the other answers 'is the network to it healthy', and they serve different purposes even though both may use ping.

The Core web interface shows the current state of every host and service (OK, WARNING, CRITICAL, and so on), a tactical overview of your whole environment, and the history of state changes and notifications. It's how you see at a glance what's healthy and what's on fire.

It also lets you take actions: schedule downtime for planned maintenance, acknowledge a problem so it stops paging while you work it, and disable checks or notifications temporarily. It's read-and-act, not just a passive dashboard.

When a check first fails, the state becomes SOFT and Nagios starts rechecking at the retry_interval instead of the normal interval. It stays SOFT while it retries, up to max_check_attempts times. This whole phase is Nagios asking 'is this a real problem or just a blip?' before it decides to bother anyone about it.

Once the retries are exhausted and the check is still failing, the state flips to HARD. That's the point Nagios treats the problem as confirmed and sends notifications. The whole SOFT phase exists so a single transient failure doesn't page anyone; only a persistent one does.

On the Nagios server, a service is configured to use check_nrpe, pointing at the remote host and naming a command like check_disk. When the check fires, check_nrpe connects to the NRPE daemon on the remote host over TCP (port 5666 by default).

The NRPE daemon looks up that command name in its own nrpe.cfg, runs the corresponding local plugin (the actual check_disk on that machine), and returns the exit code and output back to check_nrpe, which hands it to Nagios. The key point is the command must be defined on the remote host, and allowed_hosts must include your Nagios server.

NRPE is the standard active method: the Nagios server reaches out to a daemon on the remote host and runs a local plugin on demand, then reads back the result. It's a pull model, always initiated by Nagios, and it's what most teams reach for first when they need local metrics off a Linux host.

NSCA is for passive checks: the remote host pushes results in to Nagios, which suits things that report on their own schedule or hosts that can't be reached inbound. check_by_ssh runs the plugin over an SSH connection instead of a dedicated daemon, which avoids running NRPE but adds SSH overhead per check and needs key management.

Flapping is when a host or service changes state too often, bouncing between OK and CRITICAL over and over in a short window. Left alone, that generates a storm of notifications because each transition can fire its own alert, and people quickly start tuning the noisy service out entirely, which is dangerous.

Nagios tracks recent state changes and calculates a percent-change value. When it crosses a high threshold, Nagios marks the object as flapping, suppresses its notifications, and logs it, then clears the flag once the state settles below a low threshold. It stops one unstable service from paging you twenty times in ten minutes.

Acknowledging a problem tells Nagios 'I've seen this and I'm working on it', which stops the repeat notifications for that specific active problem while leaving it clearly visible as a problem in the UI. You acknowledge after something has already broken, once a human has picked it up, so the team stops getting paged about work that's already in hand.

Scheduled downtime is planned ahead: you tell Nagios a host or service will be in maintenance from time A to time B, and it suppresses notifications during that window. Downtime is for expected outages (a deploy, a patch); acknowledgement is for an unexpected one you're already handling.

Dependencies suppress checks or notifications for one object based on the state of another. A service dependency can say 'don't notify about the app if the database it depends on is already CRITICAL', so you get one meaningful alert instead of a cascade.

There are execution dependencies (skip the check entirely) and notification dependencies (still check, but don't alert). This is separate from parent-host relationships, which handle network reachability. Together they cut the noise when one root failure knocks out everything downstream of it.

An escalation changes who gets notified, or how often, after a problem has persisted through a number of notifications. The first alerts go to the on-call engineer; if it's still broken after, say, the third notification, it escalates to the team lead, then to a manager.

You define escalations with first_notification and last_notification ranges tied to a contact group. The point is that a problem nobody's fixing shouldn't stay quiet at one person's desk; escalation makes sure it climbs until someone acts.

A timeperiod is a named block of time, like 24x7 or workhours, defined by weekdays and hour ranges. Hosts and services reference them through check_period, which controls when checks are allowed to run, and notification_period, which controls when alerts are allowed to go out. So the same object can be checked constantly but only page during certain hours.

This lets you say 'check this all the time, but only page me for non-critical services during business hours'. It also handles exceptions like holidays. Getting timeperiods right is how you avoid 3am pages for things that can wait until morning.

Performance data is the extra metrics a plugin emits after a pipe symbol in its output line, like response time in milliseconds or percent used. Nagios can capture and forward it, but Core itself doesn't graph or store long-term trends, so on its own it tells you the current state and not the history behind it.

To turn it into graphs you add a tool such as PNP4Nagios, Nagiosgraph, or a Grafana pipeline. You enable process_performance_data, point Nagios at the tool's handler, and it collects the values into round-robin databases and renders history. This is how you get trends, not just up-down status.

Always verify before you reload. Run Nagios in pre-flight check mode against your config; it parses everything and reports errors and warnings without touching the running instance. A typo in one object can otherwise stop the whole daemon from starting.

Only once the check passes do you reload. A reload re-reads the config while keeping state, so you don't lose current problem status or restart every check. The discipline is verify, then reload, never blindly restart on a config you haven't validated.

OCSP and OCHP, the obsessive compulsive service and host processor commands, run after every single check on the check result, regardless of whether the state was OK or a problem. Their classic use is forwarding those results from one Nagios instance to another, which is why they exist at all in a normal setup.

In a distributed setup, a worker Nagios runs the checks and its OCSP command pushes each result up to a central Nagios via NSCA as a passive check. That way the central instance sees everything without running the checks itself. It's the plumbing behind distributed monitoring.

A check command runs the check that actually determines state. An event handler is a separate, optional command Nagios runs when a state changes, so it can react automatically rather than just record the change. It's your chance to attempt a fix before, or instead of, paging a human out of bed at 3am for something a script could handle.

For example, if a service goes CRITICAL, an event handler could restart it on the first SOFT failure and only let it page if the restart didn't help. Event handlers fire on both SOFT and HARD transitions, so you can act early. They can do a lot, but keep them safe and idempotent so they don't make an incident worse.

You run multiple worker Nagios instances, each monitoring a slice of the environment such as a data center or a region, and one central instance that aggregates all of it. The workers do the actual checking close to what they monitor, while the central instance holds the whole picture and gives you a single place to look.

Each worker forwards its results to the central instance as passive checks, classically via an OCSP command sending over NSCA. The central instance is configured with those services as passive so it just processes what arrives. This spreads check load and keeps a single pane of glass, at the cost of more moving parts to run.

Base thresholds on what's actually actionable, not round numbers. For disk, warn early enough that someone has time to react before it fills (say 80 percent) and go critical where you genuinely risk an outage (90 to 95). The gap between warning and critical is your reaction window.

Then tune against reality: look at normal ranges over time and set thresholds above the noise so you don't alert on healthy fluctuation. A threshold that fires every day and gets ignored is worse than no threshold, because it trains people to dismiss the alert.

A hostgroup is a named set of hosts, like all-linux-servers or dc-west, so you can apply a service to every member at once and view them together in the UI. A servicegroup is a named set of services across hosts, like all-web-http, so you can see and report on a class of checks as a unit.

You reach for hostgroups when the same check should run on many machines: define the disk service against the linux-servers hostgroup and every Linux host gets it automatically as you add hosts to the group. Servicegroups are more about grouping for dashboards, reporting, and dependencies than about applying checks. Both keep a large config from turning into thousands of repeated definitions.

When a check runs, its result is written to a check result file in a spool directory rather than being processed the instant it finishes. A reaper process then periodically collects those result files in batches and feeds them into Nagios so it can update the corresponding host and service states. It's a queue between running a check and acting on it.

The check_result_reaper_frequency controls how often that harvesting happens. Understanding this matters at scale: if checks pile up faster than they're reaped, results lag, and you tune reaper frequency and worker settings to keep up. It's the internal pipeline behind 'run check, update status'.

The first lever is spreading the check load: distributed workers each handling a slice, forwarding results to a central instance, so no single box runs everything. Alongside that, use a performance-oriented event broker or replace the default result handling with a faster path so the scheduler isn't the bottleneck.

Then attack the config itself. Flat files with thousands of hand-written objects become unmanageable, so you generate config from a source of truth (a CMDB or automation), lean heavily on templates and hostgroups, and profile which checks are expensive. At real scale, many teams evaluate a fork or a different tool, and being honest about when Nagios stops being the right fit is a production signal.

Nagios has no built-in clustering, so HA is something you build. The common pattern is an active/passive pair: a primary runs the monitoring, and a standby is ready to take over. You keep configs in sync and use a fencing or heartbeat mechanism so the standby only becomes active if the primary is truly down.

The subtle part is avoiding duplicate or missed notifications during failover. You either run the standby with notifications disabled until it's promoted, or coordinate so only one instance alerts at a time. The honest point to make: monitoring the monitor matters, because a silently dead Nagios is worse than no monitoring, since everyone assumes green.

Treat the config as code and generate it. Keep a source of truth (a CMDB, an inventory, cloud tags) and render Nagios objects from it with a tool like Ansible, Puppet, or a custom generator, so adding a host to inventory automatically produces its monitoring. Hand-editing thousands of files doesn't survive.

Structure heavily with templates, hostgroups, and servicegroups so a change lands in one place and applies everywhere. Put the generated config in version control, run the pre-flight check in CI before it ships, and reload only on a clean check. That pipeline is what keeps large Nagios estates from drifting into chaos.

Lock down NRPE at the daemon: set allowed_hosts to only your Nagios servers, keep dont_blame_nrpe off so remote command arguments can't be injected, and firewall port 5666 so only the monitoring host can reach it. NRPE runs commands, so an open one is a foothold.

Encrypt the traffic. Modern NRPE supports TLS, so use certificate-based encryption rather than the weak default, and prefer defining exact commands on the remote side over allowing arbitrary arguments. The threat to name is that a monitoring agent that runs plugins is effectively remote code execution if it's misconfigured.

Attack it structurally. Use dependencies so one root failure produces one alert instead of a cascade, parent-host relationships so a dead router doesn't page for everything behind it, and flapping detection so an unstable service doesn't fire twenty times. Route low-priority issues to a ticket or a dashboard, not a page.

Then tune ruthlessly: every alert that never leads to action gets deleted or its threshold raised. Set notification_period so non-urgent things stay quiet overnight, and use escalations so genuine problems climb rather than repeat at one person. The goal is that a page always means 'a human must act now', or people start ignoring pages.

Run the plugin by hand exactly as Nagios does, with the same arguments, and read the exit code and output. That immediately tells you whether the plugin genuinely sees a problem or is misfiring. Often it's a timeout too short for a slow-but-healthy service, or a threshold set below normal load.

If the manual run is clean, the difference is usually environment: Nagios runs the plugin as a different user, with a different PATH, or through NRPE with its own limits. Check permissions, the user context, and NRPE's command definition and timeout on the remote side. False positives are almost always the check's fault, not the service's.

Reach for Nagios when the job is host-and-service up-down checking on a relatively stable estate: is this server alive, is this port open, is this disk full. Its plugin library covers almost anything, and the check-based model is simple to reason about and alert on.

Reach for Prometheus when you're in a dynamic, container-heavy, cloud-native world with lots of numeric metrics you want to query and trend. Its pull-based scraping, label model, time-series storage, and PromQL fit auto-scaling fleets and Kubernetes far better. Many shops run both: Nagios or a check-based tool for classic infrastructure, Prometheus for the app and container layer.

Start from user impact and work back. Monitor the things whose failure a user would feel (is the site up, are responses fast, is the queue draining) before deep resource metrics. Then add the infrastructure signals that predict those failures, like disk filling or a certificate about to expire.

Over-monitoring shows up as alerts nobody acts on and dashboards nobody reads. Every check should answer 'what would I do if this fired?'. If the technical answer is 'nothing', it's a metric to graph, not an alert to page on. The discipline is fewer, meaningful alerts over exhaustive coverage that trains people to ignore the noise.

For certificate expiry, use a plugin like check_http with its certificate option, or check_ssl_cert, and set warning and critical on days remaining, warn at 30 days, critical at 7, so renewals happen before an outage. It's a classic 'predictable failure you should never be surprised by'.

Freshness checking handles passive checks that stop arriving. You enable check_freshness with a freshness_threshold, and if no passive result comes in within that window, Nagios runs a fallback active check or marks it stale. That catches the silent case where a reporting job died and simply stopped sending results, which otherwise looks falsely healthy.

The mismatch is that Nagios expects fairly static, named hosts, while cloud instances come and go with autoscaling. You bridge it by generating config from the cloud's own inventory: query the API or tags on a schedule, render host and service objects, verify, and reload. New instances get monitored automatically; terminated ones get removed instead of alerting as DOWN forever.

You also lean on the cloud provider's own metrics for the elastic layer and reserve Nagios for the parts that are stable enough to name. The honest senior take is that for a fully dynamic, container-native stack, a pull-based tool built for churn is often the better fit, and Nagios is best kept for the durable infrastructure.

Write a program in any language that does your check and follows the plugin contract: exit 0 for OK, 1 for WARNING, 2 for CRITICAL, 3 for UNKNOWN, and print a single summary line. Optionally append performance data after a pipe so it can be graphed.

Then wire it in like any built-in: define a command that calls it, reference that command from a service, and pass thresholds as arguments. Keep it fast and give it a sane timeout, because a plugin that hangs ties up a check slot. The whole point of the contract is that Nagios can't tell your plugin from check_http.

With retain_state_information enabled, Nagios writes current status, meaning states, acknowledgements, downtime, and disabled checks, to a retention file and reads it back on startup. Without it, a restart wipes everything back to a pending state, and you lose all that context the moment you reload, which is why it's on in any real deployment.

It matters operationally: after a reload or restart you don't want acknowledged problems to un-acknowledge and re-page, or scheduled downtime to vanish mid-maintenance. Retention keeps the human decisions you made sticky across restarts, which is why it's on in any real deployment.

Notifications in Nagios are just commands, so you point them at whatever you use. Instead of only sending email, define a notification command that calls a script or webhook to push the alert into PagerDuty, Opsgenie, Slack, or a ticketing system, passing the state and details via macros.

The better integrations are two-way: the on-call tool handles escalation, scheduling, and acknowledgement, and can push an acknowledgement back into Nagios so state stays consistent. This lets Nagios do the checking it's good at while a dedicated tool handles the human routing it isn't built for.

Watch check latency and execution time. Latency is how late a check ran versus when it was scheduled; if that climbs, the scheduler can't keep up and your status is stale. Execution time flags slow plugins hogging slots. Nagios exposes these, and you should monitor Nagios with them.

When latency grows, the fixes are the usual scaling levers: spread checks to distributed workers, widen check intervals where sub-minute resolution isn't needed, fix or timeout slow plugins, and tune the reaper and worker counts. A monitoring system that's silently lagging is dangerous because everyone trusts it to be current.