> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flashduty.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Reference Variables

> Customize incident severity, title, and other information by referencing alert labels and attributes

## Overview

By referencing variables from alert labels and attributes, you can modify and customize incident severity, title, description, and other information. This is primarily used in two scenarios:

<CardGroup cols={2}>
  <Card title="Event API Reporting" icon="code">
    When reporting custom alert events via the alert [Event API](/en/on-call/integration/alert-integration/alert-sources/standard-alert), you can use the `title_rule` field to customize the alert title.
  </Card>

  <Card title="Alert Pipeline" icon="filter" href="/en/on-call/integration/alert-integration/alert-pipelines">
    Reference variables in alert pipelines to modify alert severity, title, description, and other information.
  </Card>
</CardGroup>

### Event API Example

```json title_rule theme={null}
{
  "title_rule": "[TPL]${resource} / ${check}"
}
```

<Note>
  Specifies `resource` and `check` labels as the alert title.
</Note>

### Alert Pipeline Example

<Frame>
  <img src="https://download.flashcat.cloud/flashduty/doc/en/fd/bianliang-1.png" alt="Reference Variables in Alert Pipeline" />
</Frame>

## Variable Reference Methods

### Reference Labels via `${var}`

Use `[TPL]` as prefix and `${}` to reference variables. Variable content is extracted from labels; if extraction fails, `<no value>` is used as a placeholder.

| Rule                           | Label Values                                         | Generated Content        |
| ------------------------------ | ---------------------------------------------------- | ------------------------ |
| `[TPL]${resource} / ${check}`  | `{"resource": "127.0.0.1", "check": "cpu idle low"}` | 127.0.0.1 / cpu idle low |
| `[TPL]${resource} / ${check}`  | `{"resource": "127.0.0.1"}`                          | 127.0.0.1 / `<no value>` |
| `[TPL]${resource} / Host Down` | `{"resource": "127.0.0.1"}`                          | 127.0.0.1 / Host Down    |

### Reference via Golang Template Syntax

Use `[TPL]` as prefix and `{{}}` to reference variables (can reference both labels and attributes); if extraction fails, returns an empty string for missing labels.

| Rule                                            | Variable Values                                      | Generated Content        |
| ----------------------------------------------- | ---------------------------------------------------- | ------------------------ |
| `[TPL]{{.Labels.resource}} / {{.Labels.check}}` | `{"resource": "127.0.0.1", "check": "cpu idle low"}` | 127.0.0.1 / cpu idle low |
| `[TPL]{{.Labels.resource}} / {{.Labels.check}}` | `{"resource": "127.0.0.1"}`                          | 127.0.0.1 /              |
| `[TPL]{{.EventSeverity}} / Host Down`           | `{"EventSeverity": "Warning"}`                       | Warning / Host Down      |

<Note>
  `${}` syntax and `{{}}` syntax have two key differences:

  * **Data scope**: `${name}` reads **only** from `Labels` and cannot reference attribute fields; `{{}}` uses the whole `*AlertEvent` as the data source, so you can access every exported attribute as well as `Labels`.
  * **Missing-value behavior**: when a label is missing, `${}` returns `<no value>` while `{{}}` returns an empty string.
</Note>

#### Supported Attributes

When you use `{{}}` syntax, the template data object is the alert event (`AlertEvent`) itself. The main fields you can reference are listed below:

| Field             | Type   | Description                                                                           |
| ----------------- | ------ | ------------------------------------------------------------------------------------- |
| `Title`           | string | Alert title                                                                           |
| `Description`     | string | Alert description                                                                     |
| `EventSeverity`   | string | Severity (Critical / Warning / Info)                                                  |
| `EventStatus`     | string | Event status (Critical / Warning / Info / Ok, where Ok indicates recovery)            |
| `AlertKey`        | string | The alert's unique key, used to merge events from the same series into a single alert |
| `TitleRule`       | string | The title-generation rule supplied at report time                                     |
| `IntegrationType` | string | Integration type (such as `prometheus` or `zabbix.v5`)                                |
| `IntegrationName` | string | Integration name                                                                      |
| `Labels`          | map    | Label key-value set; access a specific label with `{{.Labels.xxx}}`                   |

<Tip>
  Besides the title, **the alert description and any label value also support reference variables**: in an alert pipeline, when you use the `Reset Description` (resetDescription) or `Reset Labels` (resetLabels) action, any content prefixed with `[TPL]` goes through the same variable substitution.
</Tip>

## FAQ

<AccordionGroup>
  <Accordion title="What happens if a label doesn't exist when using labels to dynamically generate titles?">
    Depending on which variable retrieval method you use, the title may retain the original variable information or use `<no value>` as a placeholder.

    <Tip>
      Even if a variable cannot be retrieved, it won't affect alert generation. You can debug with confidence.
    </Tip>
  </Accordion>
</AccordionGroup>