---
title: Periodic Rules
id: "en:tracking:admin:periodical-rules.adoc"
site: en
component: tracking
module: admin
version: 3.0
lang: en
url: "https://help.rtlscloud.io/en/tracking/3.0/admin/periodical-rules.html"
source_repo: "https://github.com/iot-invent/xCloud.git@3.0.x"
source_path: "tracking/docs/en/modules/admin/pages/periodical-rules.adoc"
---

# Periodic Rules

Periodic rules are executed automatically by the tracking system at fixed time intervals. Unlike event-based rules, which react to incoming localization data, periodic rules evaluate the current state of assets independently of new events — for example based on the last tag update, the current location or the asset metadata.

Typical use cases:

-   detect assets that stopped reporting

-   trigger automated relocations

-   generate localization events

The execution interval is defined by the **period** parameter (in minutes). With `period = 5` the rule runs every five minutes.

## Structure of a rule

A periodic rule consists of a schedule and a configuration that describes its behaviour. The configuration is stored as YAML and evaluated on every execution.

| Parameter | Description |
| --- | --- |
| name | Name of the rule |
| period | Execution interval in minutes |
| configuration | YAML configuration describing the rule logic |

## Rule types

Currently one rule type is available:

| Type | Description |
| --- | --- |
| timeout | Detects assets that have not received a tag update within a defined time |

Additional types may be added in future versions.

## Timeout rule

The timeout rule checks assets in the configured source locations. If an asset’s last tag update is older than the configured time, an action is triggered. This can be used to detect inactive assets, missing tag updates or devices that stopped transmitting.

Example configuration

```yaml
ruleType: timeout
sourceLocations:
  - storage
targetLocation: quarantine
timeout: 10
fireLocalizationEvent: true
```

| Parameter | Type | Description |
| --- | --- | --- |
| ruleType | Text | The rule type; for the timeout rule `timeout` |
| sourceLocations | List | Locations whose assets are monitored. Child locations are included. |
| targetLocation | Text | Location assigned to the asset when the condition is met |
| timeout | Number | Time in minutes. The rule triggers when the last tag update is older. |
| fireLocalizationEvent | Yes/No | `true` generates a localization event, `false` updates the asset location directly. |

> **TIP:** If sourceLocations contains a parent location (e.g. warehouse), the assets in all child locations (zoneA, zoneB …) are evaluated as well.

## Processing

On every execution the rule loads its configuration, resolves the source and target locations, searches for assets that have a tag assigned and sit in one of the source locations with a last tag update older than the timeout, and runs the configured action. In the example, assets without an update for ten minutes are processed as if they had been detected in `quarantine`.

## Valid configuration

A configuration is valid when `targetLocation` is set and `sourceLocations` is not empty.

## Troubleshooting

The rule is not executed

-   Is the rule active?

-   Is `period` greater than 0?

-   Is the YAML configuration valid?

Assets are not detected

-   Do the assets have tags assigned?

-   Are the assets located in the configured `sourceLocations`?

-   Is the timeout threshold reached?