Hosts already declare parents, and a parent going hard DOWN marks everything behind it UNREACHABLE (see State model). That covers one shape of dependency: a host being unreachable because the network path to it is broken. It says nothing about a service depending on another service, or on something that is not a host at all, such as a shared database or a business process. The dependencies block covers that: an explicit dependency names its dependents, a rule over its masters, and which outcomes of that rule count as failed. While a dependency is failing, the notifications it names are suppressed.

1. The dependency block

dependencies: {
	"app-needs-db": {
		dependents: [{select: "role=app"}, {ref: "batch01/etl"}]
		on:         {ref: "db01/postgres"}
		fails_on:   ["critical", "unknown"]
		suppress:   "all"          // "all" | "problems"; Nagios silences every kind
		states:     "hard"         // "hard" | "soft"; Nagios soft_state_dependencies=0
		inherits:   false          // Nagios inherits_parent
		period:     "24x7"         // Nagios dependency_period; optional, absent = always
	}
}

Every field defaults to the behavior Nagios's own dependency directives already have, so a config written for Nagios's defaults carries across unchanged:

dependents is a host or a service, never a process: only an object with notifications to suppress can be a dependent. on is the same rule language a business process uses, so a dependency can read a single master, a label selector, a quorum over several, or a process by name. Config rejects an unknown ref, a selector matching nothing, an unknown timeperiod, and a cycle in the dependency graph, the way Nagios's own config check rejects circular dependencies.

2. fails_on, and a single ref versus a composite rule

fails_on is checked against the status on yields. When on is a single ref, that master's own status is read directly, so a master with no result yet reads as pending and one that is unreachable reads as unreachable: one master per dependency object, distinguishing those two outcomes from each other, the same way Nagios does. When on is a composite rule (select, quorum, and, or, not), the rule folds a pending member to UNKNOWN the way any business process does, so pending and unreachable in fails_on are matched against the rule's own refs instead: any ref pending or missing satisfies pending, and any ref unreachable satisfies unreachable, whatever status the rule itself resolves to.

3. suppress: all versus problems

all silences every notification kind while the dependency fails: the dependency gate runs ahead of the per-type checks, so a recovery, an acknowledgement or a downtime start on a dependent all stay quiet along with the problem. Nagios's own dependency check runs the same way. problems silences only the problem-class kinds, the same set acknowledgements and unreachability already silence, so a recovery still goes out even while the dependency is failing. See Escalations and windows section 5 for where the dependency gate sits among the others.

4. states and inherits

states: "hard" reads the masters' hard status, the confirmed state after max_attempts; states: "soft" reads their current status, whatever its type, so a single failed check on the master already trips the dependency. inherits: true chains dependencies: a master that itself depends on something failing counts as failed here too, the way Nagios's inherits_parent does.

5. period

period names a timeperiod. Outside it the dependency never fails, whatever the masters' status is. Absent, the dependency always applies.

6. Reload and recovery

A config reload swaps the whole dependencies map at once; nothing about a dependency is written to the event log or persisted between evaluations, and there is no timer to re-arm. A dependent notifies again on its next check result once the master recovers, the same way a suppressed notification behaves everywhere else in jaque.

7. Importing from Nagios

hostdependency and servicedependency objects become dependencies entries, one per dependent-master pair. notification_failure_criteria maps onto fails_on: for a hostdependency, o, d, u, p are ok, critical, unreachable, pending; for a servicedependency, o, w, u, c, p are ok, warning, unknown, critical, pending. n alone means the dependency never fails and nothing is emitted. inherits_parent and dependency_period carry across as inherits and period. execution_failure_criteria has no dependency gate to land on: the scheduler arms and disarms checks on check_period only, so it is reported unsupported and dropped. See Importer section 4.