> Section: [4. Configuration](https://jaque.sh/docs/config/cue-in-practice.md)
> Next: config/hot-reload
> Index: https://jaque.sh/llms.txt


Hosts already declare `parents`, and a parent going hard DOWN marks
everything behind it UNREACHABLE (see [State
model](../concepts/state-model.md)). 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

```cue
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:

| Field | Default | Meaning |
|---|---|---|
| `dependents` | required | a non-empty list of `{ref: "host"}`, `{ref: "host/service"}` or `{select: "..."}` targets; a selector must match at least one host or service |
| `on` | required | a [rule](https://jaque.sh/docs/concepts/business-processes.md) over the masters: a single `ref`, or any of `select`, `process`, `and`/`or`/`not`/`quorum` |
| `fails_on` | required | a non-empty list of `ok`, `warning`, `critical`, `unknown`, `pending`, `unreachable` |
| `suppress` | `"all"` | which notification kinds a failing dependency silences |
| `states` | `"hard"` | whether the rule reads the masters' hard or current status |
| `inherits` | `false` | whether a master with a failing dependency of its own counts as failed too |
| `period` | none | a timeperiod name; outside it the dependency never fails |

`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](https://jaque.sh/docs/concepts/business-processes.md) 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](../notifications/escalations-and-windows.md) 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](https://jaque.sh/docs/config/timeperiods.md). 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](https://jaque.sh/docs/nagios-compat/importer.md) section 4.