[comment]: # translation:outdated

[comment]: # aside:6

[comment]: # ({new-b4b0e364})
# Events and reaction

[comment]: # ({/new-b4b0e364})

[comment]: # ({new-3825c91b})
### Overview

There are several types of events generated in Zabbix:

-   trigger events - whenever a trigger changes its status (*OK→PROBLEM→OK*)
-   service events - whenever a service changes its status (*OK→PROBLEM→OK*)
-   discovery events - when hosts or services are detected
-   autoregistration events - when active agents are auto-registered by server
-   internal events - when an item/low-level discovery rule becomes unsupported or a trigger goes into an unknown state

Events are time-stamped and can be the basis of actions such as sending notification email, creating tickets, or executing remote commands.

To view event details in the frontend, go to *Monitoring* > *Problems*.
There you can click the event date and time to open the event details page, where you can see additional information about the event, including whether it was suppressed because of maintenance or suppressed manually by a user.

[comment]: # ({/new-3825c91b})

[comment]: # ({new-071dda8a})
### Service events

Service events are generated only if service actions for these events
are enabled. In this case, each change of service state creates a new
event:

-   Problem event - when service state is changed from **`OK`** to **`Problem`**
-   OK event - when service state is changed from **`Problem`** to **`OK`**

The event contains details of the service state change - when it
happened and what the new state is.

[comment]: # ({/new-071dda8a})

[comment]: # ({new-3ae80f24})
### Discovery events

Zabbix periodically scans the IP ranges defined in network discovery
rules. Frequency of the check is configurable for each rule
individually. Once a host or a service is discovered, a discovery event
(or several events) are generated.

Zabbix generates the following events:

|Event|When generated|
|--|--------|
|Service Up|Every time Zabbix detects active service.|
|Service Down|Every time Zabbix cannot detect service.|
|Host Up|If at least one of the services is UP for the IP.|
|Host Down|If all services are not responding.|
|Service Discovered|If the service is back after downtime or discovered for the first time.|
|Service Lost|If the service is lost after being up.|
|Host Discovered|If host is back after downtime or discovered for the first time.|
|Host Lost|If host is lost after being up.|

[comment]: # ({/new-3ae80f24})

[comment]: # ({new-5d514e59})
### Active agent autoregistration events

Active agent autoregistration creates events in Zabbix.

If configured, active agent autoregistration event is created when a
previously unknown active agent asks for checks or if the host metadata
has changed. The server adds a new auto-registered host, using the
received IP address and port of the agent.

For more information, see the [active agent
autoregistration](/manual/discovery/auto_registration) page.

[comment]: # ({/new-5d514e59})

[comment]: # ({new-d156b0a7})
### Internal events

Internal events happen when:

-   an item changes state from 'normal' to 'unsupported'
-   an item changes state from 'unsupported' to 'normal'
-   a low-level discovery rule changes state from 'normal' to
    'unsupported'
-   a low-level discovery rule changes state from 'unsupported' to
    'normal'
-   a trigger changes state from 'normal' to 'unknown'
-   a trigger changes state from 'unknown' to 'normal'

The aim of introducing internal events is to allow users to be notified when any internal event
takes place, for example, an item becomes unsupported and stops gathering data.

Internal events are only created when internal actions for these events
are enabled. To stop generation of internal events (for example, for
items becoming unsupported), disable all actions for internal events in *Alerts* > *Actions* > *Internal actions*.

::: noteclassic
 If internal actions are disabled, while an object is in the 'unsupported' state, recovery event for this object will still be created.

If internal actions are enabled, while an object is in the 'unsupported'
state, recovery event for this object will be created, even though
'problem event' has not been created for the object. 
:::

See also: [Receiving notification on unsupported items](/manual/config/notifications/unsupported_item)

[comment]: # ({/new-d156b0a7})