Several configuration parameters define how Zabbix server should behave when an agent check (Zabbix, SNMP, IPMI, JMX) fails and a host becomes unreachable.
A host is treated as unreachable after a failed check (network error, timeout) by Zabbix, SNMP, IPMI or JMX agents. Note that Zabbix agent active checks do not influence host availability in any way.
Since Zabbix 2.4.7, if another item check was successful between two failed checks of a problematic item, the problematic item is marked as not supported after the second failed check without affecting host availability. This was removed in Zabbix 2.4.8.
From that moment UnreachableDelay defines how often a host is rechecked using one of the items (including LLD rules) in this unreachability situation and such rechecks will be performed already by unreachable pollers. By default it is 15 seconds before the next check.
In the Zabbix server log unreachability is indicated by messages like these:
Note that the exact item that failed is indicated and the item type (Zabbix agent).
The Timeout parameter will also affect how early a host is rechecked during unreachability. If the Timeout is 20 seconds and UnreachableDelay 30 seconds, the next check will be in 50 seconds after the first attempt.
The UnreachablePeriod parameter defines how long the unreachability period is in total. By default UnreachablePeriod is 45 seconds. UnreachablePeriod should be several times bigger than UnreachableDelay, so that a host is rechecked more than once before a host becomes unavailable.
If the unreachable host reappears, the monitoring returns to normal automatically:
After the UnreachablePeriod ends and the host has not reappeared, the host is treated as unavailable.
In the server log it is indicated by messages like these:
and in the frontend the host availability icon goes from green to red (note that on mouseover a tooltip with the error description is displayed):
The UnavailableDelay parameter defines how often a host is checked during host unavailability.
By default it is 60 seconds (so in this case "temporarily disabling", from the log message above, will mean disabling checks for one minute).
When the connection to the host is restored, the monitoring returns to normal automatically, too: