It's quite common that the availability of a service or a host doesn't depend only on the said host by itself, but also on the availability of any other machine that may provide connectivity to it. For example, if a router goes down, whereby an entire subnet is isolated, you would still get alerts about all the hosts in the said network that will suddenly be seen as unavailable from Zabbix's point of view even if it's really the router's fault. A dependency relationship between the router and the hosts behind it would help alleviate the problem because it would make the server skip any trigger check for the hosts in the subnet in case the router becomes unavailable. While Zabbix doesn't support the kind of host-to-host dependencies that other systems do, it does have a trigger-to-trigger dependency feature that can largely perform the same function. For every trigger definition, you can specify a different trigger upon which your new trigger is dependent. If the parent trigger is in a PROBLEM state, the trigger you are defining won't be checked until the parent returns to the OK state. This approach is certainly quite flexible and powerful, but it also has a couple of downsides. The first one is that one single host can have a significant number of triggers, so if you want to define a host-to-host dependency, you'll need to update every single trigger, which may prove to be quite a cumbersome task. In this kind of situation, probably you can simplify the problem by adding your triggers within a custom template. Anyway, if you have only specific cases, this will not help as it would end up creating a template for each host, which is not ideal and will move the problem to the template. You can, of course, rely on the mass update feature of the web frontend as a partial workaround. A second problem is that you won't be able to look at a host definition and see that there is a dependency relationship with another host. Short of looking at a host's trigger configuration, there's simply no easy way to display or visualize this kind of relationship in Zabbix.

A distinct advantage of having a trigger-level dependency feature is that you can define dependencies between single services on different hosts. As an example, you could have a database that serves a bunch of web applications on different web servers. If the database is unavailable, none of the related websites will work, so you may want to set up a dependency between the web monitoring triggers and the availability of the database. On the same servers, you may also have some other service that relies on a separate license server or an identity and authentication server. You could then set up the appropriate dependencies so that you could end up having some triggers depend on the availability of one server and other triggers depend on the availability of another one, all in the same host. While this kind of configuration can easily become quite complex and difficult to maintain efficiently, a select few, well-placed dependencies can help cut down the amount of redundant alerts in a large environment. This, in turn, would help you to focus immediately on the real problems where they arise instead of having to hunt them down in a long list of trigger alerts.