# Using Predefined Variables

In the **Custom Payload** of a **Generic Webhook**, you can use a set of predefined tags. These tags are automatically populated using the `{{ }}` syntax.

## Available Variables

Below is a list of the available tags:

| Variable                  | Description                                                                                 |
| ------------------------- | ------------------------------------------------------------------------------------------- |
| `summary`                 | The monitor title from the issue details                                                    |
| `description`             | The monitor description - can contain nested variables based on monitor definitions         |
| `monitor_name`            | The actual name of the monitor                                                              |
| `monitor_id`              | Internal unique ID of the monitor                                                           |
| `fingerprint`             | Unique ID for the specific issue (useful for deduplication)                                 |
| `severity`                | The monitor severity (S1, S2, S3, S4)                                                       |
| `status`                  | Alert state - returns "alerting" when firing, "resolved" when resolved, "test" when testing |
| `value`                   | The actual monitor value that triggered the alert                                           |
| `threshold`               | The threshold configured in the monitor                                                     |
| `timestamp`               | The firing time in UTC                                                                      |
| `renotification_count`    | Counter starting at 0, increments with each re-notification                                 |
| `alertname`               | The alert name                                                                              |
| `urls.issue`              | URL to the issue for investigation                                                          |
| `urls.monitor`            | URL to the monitor definitions                                                              |
| `urls.silence`            | URL to silence the monitor                                                                  |
| `urls.notification_route` | URL to the notification route                                                               |

## Using Labels

Any **label** from the monitor can be used with the `labels.<label>` syntax. This includes both custom labels and group-by labels.

```
{{ labels.workload }}
{{ labels.namespace }}
{{ labels.env }}
{{ labels.traceID }}
```

{% hint style="warning" %}
Labels must be included in the monitor's "group by" clause or as custom labels to be available in notifications.
{% endhint %}

## Test Mode Behavior

When using the "Test" button to validate your webhook configuration:

* `{{ status }}` returns `"test"` instead of `"alerting"`
* `{{ value }}` and `{{ threshold }}` may contain placeholder values
* Other variables are populated with sample data

## Advanced Templating with Jinja2

Generic Webhooks support Jinja2 templating for more complex scenarios:

### Conditional Content

```jinja
{% if severity == "S1" %}
:rotating_light: CRITICAL ALERT
{% else %}
:warning: Alert
{% endif %}
```

### Channel Routing (Slack)

```jinja
{
  "channel": "{% if labels.env == 'prod' %}#prod-alerts{% else %}#dev-alerts{% endif %}",
  "text": "{{ summary }}"
}
```

### Using Macros for Complex Payloads

For payloads requiring multi-level variable expansion, use Jinja macros within the description:

```jinja
{% macro build_message() %}
Alert: {{ alertname }}
Environment: {{ labels.env }}
Workload: {{ labels.workload }}
{% endmacro %}
{{ build_message() }}
```

{% hint style="info" %}
Variables inside monitor labels are not rendered. Use the description field with macros for complex templating scenarios.
{% endhint %}