---
title: "Each alert type"
canonical: "https://docs.devo.com/space/latest/95126616/Each%20alert%20type"
format: markdown
---
> Macro (toc)
## Overview
Each method triggers an alert for each event that reaches your query.
The threshold for this kind of alert is defined by the filters you have applied in the query. So, each time an event is written on the data table and meets the conditions of your query, an alert will be triggered.
This type of alert could be useful when monitoring key data and every single event needs to be considered individually.
## What data do I need to create this alert?
To create an alert using this triggering method, you can apply filters and create new fields in your query as well as group and aggregate data. However, note that this type of alert only accepts time-based grouping (they cannot be defined with queries with non-time-based grouping).
> ℹ️ **Less than 60 events**
> ℹ️
> ℹ️ Refine your query to show fewer than 60 events in the table. Otherwise, you won't be able to create the alert due to a potentially excessive number of alerts being generated.
> ℹ️
> ℹ️ 
### Using subqueries
The each type is the only one that allows the use of subqueries, however, this feature comes with certain limitations:
- Queries must not include nested subqueries.
- Queries must not include a fixed time range in the subquery.
- Queries must not include a temporal grouping in the subquery.
- Tables such as `my.lookuplist` tables (more about them [here](https://devodocs.atlassian.net/wiki/spaces/latest/pages/95203983)) can be used with some limitations :
- Only inner queries can contain them.
- The specified period cannot be less 24 hours.
Examples of valid and invalid subquery formats
| **Query** | **Allowed?** |
| --- | --- |
| ```
from T1
where x in (
from T2
where y in (
from T3
)
)
``` | This query includes nested subqueries, so it is not allowed. |
| ```
from T1
where x in (
from T2
where 100 <= eventdate < 200
)
``` | This query includes a fixed time range in its subquery, so it is not allowed. |
| ```
from T1
where x in (
from T2
group every 10m
)
``` | This query includes a temporal grouping in its subquery, so it is not allowed. |
| ```
from T1
where x in (
from T2
)
``` | This query has neither a group nor a time range in its subquery, so it is allowed. |
| ```
from T1
group by x every 10m
where x in (
from T2
)
``` | This query has a temporal grouping, but it is not included in the subquery. Therefore, it is allowed. |
## Specific settings
### Include all fields
After selecting this type of alert, you don't have to select any other setting to successfully configure it.
However, for queries that do not group data, you can decide whether you include inside the extraData all fields in the table or not. Checking the box will include all of them while leaving it unchecked will include only those explicitly specified in the query, as well as the eventdate.
As this option may imply an impact on performance, we recommend minimizing its use.
> ℹ️ **extraData**
> ℹ️
> ℹ️ The extraData is the field that consolidates the content of the different event fields related to the triggered alert to provide the user with context about the triggering conditions. More info [here](https://devodocs.atlassian.net/wiki/spaces/latest/pages/576552961).
### Internal period, internal offset, and external offset (only with subqueries)
The **Internal period** is used to set the subquery time range. For example, for an internalPeriod of 10 days, the subquery time range would be `[now() - 10d, now()]`.
The **Internal offset** is used to move the subquery time range backward in time. For example, if the subquery time range is `[now()-10d, now()]` with an internalOffset of 2 days, the time range would be `[now() -12d, now() - 2d]`.
The **External offset** is used to move the main query time range backward in time. For example, if the main query time range is `[now()-1h, now()]` with an externalOffset of 2 days, the time range would be `[now() -1h -2d, now() - 2d]`.
For all the parameters explained above, you can use preset periods or create custom periods:
- **Preset periods**: click the dropdown and select the desired option (you can use the editable field to filter them).
- **Custom periods**: click the dropdown, write the desired period in the editable field and then click the green field that appears below to confirm it. You have to introduce a valid format, otherwise, you will get an error message. The accepted format consists of a number followed by a duration code without space between them:
| **Duration** | ***Format*** | **Example** |
| --- | --- | --- |
| Days | (0-n)*d* | *1 day* → *1d* |
| Hours | (0-24)*h* | *15 hours → 15h* |
| Minutes | (0-59)*m* | *45 min → 45m* |
| Compound: you can stack the different durations to create a compound | (0-n)d(0-24)h(0-59)m(0-59)s | *15 hours, 45 minutes, 50 seconds → 15h45m50s* |
> ℹ️ **Min/max period**
> ℹ️
> ℹ️ The periods must be at least 1 minute and up to 100 days to be accepted for alert creation.
> ℹ️
> ℹ️ ***Internal period/external period***** permitted ratio**
> ℹ️
> ℹ️ > Macro (excerpt-include)
> ℹ️
> ℹ️
> ℹ️
> ℹ️ **Starting moment**
> ℹ️
> ℹ️ The period will not start counting from the moment of the alert creation but from a fixed division that takes the [Epoch reference date](https://en.m.wikipedia.org/wiki/Unix_time) as the starting point (midnight Jan 1, 1970). This means that if you created an alert past the hour with a one-hour period, the first time it will be triggered (if the conditions are met) will be when the clock strikes the hour and not after 60 minutes. In other words, if you created it at 9:37, it will be triggered at 10 and not at 10:37.
> ℹ️
> ℹ️ The period will be adjusted according to the timezone specified in the alert definition window (more info [here](https://docs.devo.com/space/latest/95126609)).
## Using field values in Summary and Description
You can use the *$fieldName* command to display in the **Summary** and **Description** fields the field values of the event that triggered the alert. This command can be employed with the name of any field present in the query result.
In the following query, you could use:
Take into account that if your query groups events, this command will only work with the names of those fields resulting from the grouping operation. Using a different one will not activate the command and will be interpreted as plain text.
In the following query, you could use:
## Query example
In the `demo.ecommerce.data` table, imagine that you want to receive an alert each time there's an event that comes from a private IP address.
First of all, you need to filter the query data using the [Is Private IPv4 (isprivate)](https://devodocs.atlassian.net/wiki/spaces/latest/pages/95199449) operation. Then, you need to open the alert definition window and select an *each* type alert.
To save time, you can copy the following query to reproduce the aforementioned example from the `demo.ecommerce.data` sample table and create an *each *type alert.
```
from demo.ecommerce.data
where isprivate(clientIpAddress)
```
**Related articles**
> Macro (children)