---
title: "Flow Policy Settings"
slug: "flow-policy-settings"
description: "Explore Kentik's Flow policy types for alerting, including settings, conditions, and baselines to optimize your network monitoring and response."
tags: ["Alerting System", "Flow Policy Settings", "Policy Configuration"]
updated: 2026-07-17T00:46:38Z
published: 2026-07-17T00:46:38Z
canonical: "kb.kentik.com/flow-policy-settings"
---

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

# Flow Policy Settings

The settings for Flow policy types in Kentik's alerting system are detailed here.

> [!NOTE]
> **Notes:**
> 
> - For more information about policy-based alerting, first read [**Alerting**](/v1/docs/alerting-4), [**Alert Policy Templates**](/v1/docs/alert-policy-templates), [**Alerting Page**](/v1/docs/alerting-page), [**Notifications**](/v1/docs/notification-channel), and [**Mitigations**](/v1/docs/mitigation-overview).
> - Alert policy configuration can be complex. Please reach out for help by contacting Kentik support (see [**Customer Care**](/v1/docs/customer-care)).

![The Add Alert Policy page with various settings and options displayed.](https://cdn.us.document360.io/082e25b5-afce-42d4-8f47-70bd3f1d02b7/Images/Documentation/AP-add-policy-page-main.png)

*The Add Alert Policy page for a Flow policy type in Kentik’s Alerting.*

## Flow Policy Settings Tabs

The following tabs are included on all types of [**policy settings pages**](/v1/docs/alert-policies-2#policy-settings-pages) (add, edit, or clone) for Flow policy types:

- [**General Settings**](/v1/docs/flow-policy-settings#general-settings): Define the overall policy properties.
- [**Dataset Settings**](/v1/docs/flow-policy-settings#dataset-settings): Narrow the subset of traffic evaluated for all thresholds.
- [**Activate & Clear**](/v1/docs/flow-policy-settings#activate-clear-settings): Manage alert triggering criteria, event frequencies, manual acknowledgments, and notification routing.
- [**Baseline**](/v1/docs/flow-policy-settings#baseline-settings): Configure the historical data buckets and aggregation methods used to establish normal traffic patterns for comparison.
- [**Dashboards & Labels**](/v1/docs/flow-policy-settings#dashboards-labels-settings) (Optional Settings): Format organizational tags and bind specific destination dashboards to a policy's alerts.

## General Settings

The **General** tab of a Flow policy settings page (add, edit, clone) includes:

- **Name**: The unique name for the alert policy.
- **Description**: An optional summary of what the policy monitors and its intended use case.
- **Enable Policy**: A switch to activate or deactivate the policy. A policy must be turned **On** to evaluate traffic and generate alerts.
- **Flow Policy Types**: Selectable cards to monitor flow-based traffic patterns:
  - **Protect**: Monitors traffic patterns indicating potential attacks (e.g., SYN floods, amplified reflections).
  - **Traffic**: Monitors NetFlow/VPC FlowLog traffic patterns, focusing on flow rate thresholds and fluctuations.
- **NMS Policy Types**: Selectable cards to monitor system, device, and network management states:
  - **Agent**: Tracks agent health metrics such as resource usage and status.
  - **Agent Capability**: Tracks capability health and enablement status.
  - **BGP Neighbor**: Monitors BGP peering session states and metrics (e.g., session state changes, advertised prefixes).
  - **Component**: Tracks device component states and hardware metrics (e.g., CPU, power supply).
  - **Device**: Monitors system-level device states and metrics (e.g., up/down status, overall CPU/memory).
  - **Event**: Filters SNMP traps or syslog messages using custom regex filters.
  - **Interface**: Tracks interface states and counter metrics (e.g., operational status, traffic spikes).
  - **Classic Threshold**: Utilizes rolling window aggregations and classic baselines for average-over-time thresholds.
  - **Custom**: Allows for any NMS measurement, including cloud and custom metrics from third-party integrations.

## Dataset Settings

The **Dataset** tab of the Flow policy settings page narrows the subset of traffic evaluated for the alert’s thresholds, as follows:

- **Data Sources**: Displays the devices and cloud resources currently selected for evaluation (e.g., All devices).
  - Click **Edit Devices** to open a [**dialog**](/v1/docs/data-source-settings#data-sources-dialog) to update the data sources covered by this policy.
- **Policy Dimensions**: Lists the traffic evaluation dimensions used to define a key (e.g., Destination IP/CIDR.
  - **v4 CIDR** & **v6 CIDR**: Set custom IPv4 and IPv6 prefix lengths when CIDR dimensions are applied to the policy (e.g., 32 and 128).
  - Click **Edit Dimensions** to choose how traffic is subdivided for evaluation (up to 8 dimensions).
- **Metrics**: Shows the policy’s currently selected metrics used to trigger the alert.

> [!NOTE]
> **Note**: Each policy can have a maximum of three metrics: one primary and two secondary.
  - **Primary**: The primary unit (e.g., Packets/s) by which traffic will be evaluated to determine the top-X ranking (see [**General Metrics**](/v1/docs/general-metrics) and [**Host Traffic Metrics**](/v1/docs/general-metrics#host-traffic-metrics)).
  - **Secondary**: A lozenge for the secondary metric (up to 2), used to specify multiple additional static comparators (see [**Policy Dataset Settings**](/v1/docs/flow-policy-settings#dataset-settings)). Each added comparator is a condition for triggering an alarm. Use the **Secondary Metrics** selector to choose up to 2 secondary metrics.
  - Click **Edit Metrics** to modify primary and secondary metrics (see [**About the Metrics Dialog**](/v1/docs/metrics-settings#about-the-metrics-dialog)).
- **Filters**: Displays any currently applied filtering criteria (see [**About Filters**](/v1/docs/filtering-settings#about-filters)).
  - Click **Edit Filters** to apply or edit custom criteria that narrow the scope of evaluated traffic (see [**Filters Dialog**](/v1/docs/filtering-settings#filters-dialog)).

### Advanced Settings

Click the expander arrow to reveal the **Advanced Settings** pane with additional configuration options for tailoring your dataset evaluation:

- **Building Your Dataset**: A summary explaining that the dataset begins with all traffic matching the policy's dimension keys, ranks them by the primary metric, and evaluates the top-X keys.

> [!NOTE]
> **Note**: When you select multiple dimensions, the [**Dimension Grouping**](/v1/docs/flow-policy-settings#dimension-grouping) controls also become active in this section.
- **Evaluation Frequency**: The time interval represented by a single data point in the dataset (**60 Seconds**, **2 Minutes**, or **5 Minutes**).
- **Maximum Keys Per Evaluation**: The maximum number of keys in the overall pool, combined from all groups if dimension grouping is enabled (default: 25).

#### Dimension Grouping

If you’ve included more than one dimension, the Advanced Settings pane also includes the following **Dimension Grouping** controls:

- ![Overview of Dimension Grouping settings for a Flow policy type.](https://cdn.us.document360.io/082e25b5-afce-42d4-8f47-70bd3f1d02b7/Images/Documentation/Screenshot 2026-07-13 at 3.48.12 PM.png)**Dimension Grouping** (switch): Select **Enabled** to group traffic by dimensions before the final top-X evaluation.
- **Grouping Summary**: A dynamically generated plain-text summary explaining exactly how the system will evaluate your configured groups and keys.
- **Dimensions to Group By**: Specify the number of dimensions, starting from the top of your selected Policy Dimensions list, to form the basis for grouping.
- **Maximum Keys per Group**: Use the selector to choose the number of keys from each group to include in the overall top-X pool. Value cannot exceed 300.

> [!NOTE]
> **Note**: This value cannot exceed the limit set in **Maximum Keys Per Evaluation**.

## Activate & Clear Settings

An alert policy's **Activate & Clear** settings define the exact set of conditions that must match for the policy to enter an alarm state. Upon activation, the policy generates an alert for each key where the conditions are met. These settings manage alert triggering criteria, event frequencies, manual acknowledgments, mitigations, and notification routing.

![Configuration settings for alert policies including conditions and frequency options.](https://cdn.us.document360.io/082e25b5-afce-42d4-8f47-70bd3f1d02b7/Images/Documentation/Screenshot 2026-07-13 at 4.14.13 PM(1).png)

### Global Options

- **Suppress Alerts**: A toggle switch that engages [**Alert Suppressions**](/v1/docs/alert-suppressions) for this policy. When turned **On**, the policy will not enter an alarm state, trigger notifications, or initiate mitigations until a specified end date (ideal for establishing new policy baselines or staging).

> [!NOTE]
> **Notes:**
> 
> - Alert suppressions are enabled by default for query-based policies.
> - Alert suppressions can be enabled on a pattern basis on the [**Alert Suppressions & Silences Page**](/v1/docs/alert-suppressions#alert-suppressions-silences-page).
  - **Suppress Alerts End Date**: If **Suppress Alerts** is switched on, specify the date on which the alert suppressions will end. The default is seven days.

### Severity Tiers

Each policy includes at least one active threshold but can evaluate up to five severity tiers simultaneously. Select from the horizontal tabs (**Minor**, **Warning**, **Major**, **Severe**, **Critical**) to configure properties per level:

- **Enable Toggle**: Turns the selected severity threshold **On** or **Off**. Disabled thresholds can be retained for future use without evaluating traffic.
- **Description**: A free-form text box to document the unique intent or monitored conditions of the specific severity level.

### Conditions

The **Conditions** pane is where you define the technical rules that constitute a match. If multiple conditions are selected, all of them must evaluate to true simultaneously to trigger the alert. At least one condition is required:

- **Static Condition**: Evaluates current metric data directly against a fixed numeric threshold value (e.g., if traffic is at least 100 packets). Click **Show Chart** to display a visualization of recent data.
- **Baseline Condition**: Evaluates current metrics against a rolling historical baseline (e.g., if traffic is at least 20% above the baseline).

> [!NOTE]
> **Note**: Requires a **Static Condition** to be active.
- **Top Keys Condition**: Evaluates changes in the composition of the top-X keys (e.g., when a key joins or leaves the top keys in current traffic).
- **Interface Capacity Condition**: Triggers alerts based on an interface’s current utilization relative to its total capacity.

> [!NOTE]
> **Note**: Requires the **Bits/s** metric and an **Interface** dimension.
- **Ratio-Based Condition**: Evaluates the ratio between two different metrics.

> [!NOTE]
> **Note**: Requires at least 2 metrics to be selected on the **Dataset** tab.

### Frequency

The **Frequency** pane is where you control the temporal parameters required to confirm a genuine alert state and prevent "flapping":

- **Trigger Threshold**: Requires the above conditions to be met at least X times within a rolling window of Y [Minutes/Hours].
- **Reset Period**: The duration (in minutes) of continuous activity-free metrics required to completely reset the condition counters back to zero.

### Acknowledgement Required

- **On/Off Toggle**: When enabled (On), incoming alerts initially enter an "Ack Required" state, requiring manual confirmation from an operator via the active alert workflows before they can be cleared or resolved.

### Mitigations

> [!NOTE]
> **Note**: This section is only visible when a Flow-based policy’s dimensions include source or destination IP/CIDR.

- **Mitigation Selector**: Choose one or more automated mitigations to activate when this threshold is triggered to protect network availability from undesirable traffic. (Automated mitigations will escalate and de-escalate automatically as changing conditions match different thresholds).

### Notifications

- **Notification Channels**: A multi-select field to assign where alerts are routed when triggered (e.g., Slack, PagerDuty, Email).
- **Add New Channel**: Click to open the [**Add Notification Channel**](/v1/docs/notification-channel#add-or-edit-notification-channel) page to build and bind a brand new notification destination directly from the policy workflow.
- **Test Notification Channels**: Click the button to initiate a test notification to the selected channels.

### Fallback Settings

> [!NOTE]
> **Note**: This section dynamically appears only when your conditions compare current values to baseline values).

- **When Baseline Values Are Missing**: A dropdown that determines how to handle a missing comparison value if a key in the primary top-X is missing from the historical baseline set. Options include:
  - Use Lowest Value from Top Keys (Default)
  - Use Highest Value from Top Keys
  - Use a Default Value
  - Do Not Alert
  - Activate an Alert
- **Fallback Value**: Specify the static numeric fallback value to use for the metric if no baseline top key values exist (e.g., if baselining has not yet finished accumulating data).

## Baseline Settings

Baselining triggers alerts based on comparing current traffic values to a baseline. Derived from historical traffic patterns, the baseline represents "normal" values for a key. If the current value deviates from the norm and matches an alert policy threshold condition, the threshold triggers an alert.

Baselining starts with a historical data set:

- Covers traffic funneled similarly to the current traffic (see [**Policy Dataset Settings**](/v1/docs/flow-policy-settings#dataset-settings)).
- Covers a specified time range (baseline window).
- Includes time series data points representing traffic volume for a top-X key over a duration (1, 2, or 5 min) determined by the Dataset tab's **Evaluation Frequency** setting.

Two main stages build the baseline:

- **Building the baseline**: Smoothing spikes or drops in normal traffic by normalizing/averaging data points for each top-X key over the baseline window (options in [**Building the Baseline**](/v1/docs/flow-policy-settings#building-the-baseline)). The result is "buckets" each with a duration of one hour and with values for each of the top-X keys.
- **Using the baseline**: Choosing and normalizing/averaging key values in selected buckets into a final historical value for each key (options in [**Using the Baseline**](/v1/docs/flow-policy-settings#using-the-baseline)). The final baseline value is then used in comparisons in the conditions of each threshold.

A match between the current value and the final baseline value triggers an alert, depending on the threshold’s [**Frequency**](/v1/docs/flow-policy-settings#frequency) settings.

> [!NOTE]
> **Note:** Historical baseline settings in a policy apply to all thresholds with baseline conditions.

![](https://cdn.us.document360.io/082e25b5-afce-42d4-8f47-70bd3f1d02b7/Images/Documentation/image(312).png)

*For each one-hour bucket, the value of a given key (red bar) is derived from the time-slice values for that key.*

### Baseline Presets

Select one of the cards at the top of the Baseline tab to instantly apply a baseline configuration:

- **DEFAULT**: Builds a purpose baseline collecting 25 keys an hour, going back 4 weeks. Recommended for most general baseline uses.
- **PRECISION**: Builds a baseline collecting 300 keys an hour, going back 4 weeks. Recommended for the most accurate sample of network behavior.
- **EXPRESS**: Builds a baseline collecting 25 keys an hour, going back 1 week. Recommended for creating a quick baseline for general alerting.
- **CUSTOM**: Builds a baseline with flow data specifications of your choosing. Automatically selected if you manually alter any of the preset values below.

### About Your Baseline

The ‘About your baseline’ section is a dynamically generated text block that confirms what data is being measured. It displays the primary metric (e.g., Packets/s) and the time interval for datapoints (e.g., 60 Seconds) based on your selections in the **Dataset** tab.

### Building the Baseline

This pane (under Advanced Options on the **Baseline** tab) helps you determine how the historical data buckets are built:

- **Window**: Determines the number of buckets by going back a specified duration (e.g., 4 weeks) from a specific endpoint (e.g, 1 day ago):
- **Bucket Depth**: The number of top-X keys collected in every hour of the window. Defaults to the **Maximum Keys per Evaluation** setting (see [**Advanced Settings**](/v1/docs/flow-policy-settings#advanced-settings)).
- **Rollup Aggregation**: The mathematical method (e.g, 98th Percentile, Maximum, Minimum) used to derive each key’s value for the one-hour bucket.

> [!NOTE]
> **Note:** The baseline window is "rolling," meaning older traffic data ages out and newer data is added continuously.

### Using the Baseline

The Using the Baseline pane determines how comparison values are derived from your buckets:

- **Compare to**: Determines which buckets are used to establish the baseline (e.g., the current hour of every day of the week).
- **Bucket width**: Derives the value for each "compare to" hour from just that hour or by aggregating surrounding hours.

> [!NOTE]
> **Note**: If aggregating surrounding hours, you can choose to aggregate 1 to 4 hours before and after the nominal hour, using minimum, maximum, or a specific percentile (5th, 10th, 25th, 50th, 75th, or 90th).
- **Final aggregation**: The mathematical method (e.g., 95th Percentile) used to combine the key’s values into the final comparison value.
- **Use separate patterns for weekdays and weekends**: A checkbox that calculates baselines for UTC weekends independently from UTC weekdays to account for varying traffic patterns.

> [!TIP]
> **Tip:** Policies watching for excess activity usually use Maximum, 98th, or 95th percentile aggregation. Policies watching for below-baseline activity typically use 25th percentile aggregation.

## Dashboards & Labels Settings

The **Dashboards & Labels** tab (located under Optional Settings) allows you to organize your policy and associate it with relevant visualization tools within the Kentik platform.

### Labels

Apply [**labels**](/v1/docs/labels), i.e. organizational tags, to group, sort, and filter your alert policies across the controller view.

- **Apply labels to this policy...**: Click the dropdown menu to open the label selector. You can type to filter the list or check the boxes next to existing labels to assign them.
- **Select All / Clear**: Quick-action links to instantly select all available labels or remove all current checkboxes.
- **Add Label**: A link that opens the [**Label Controls**](/v1/docs/tests-page#label-controls) in a new browser tab to let you create a brand new label from scratch.

### Dashboard

Associate a specific dashboard to be linked directly from alerts generated by this policy.

- **Dashboard Selector**: Click to choose an existing [**Dashboard**](/v1/docs/dashboards#about-dashboards) from the dropdown, filtering by dashboard name as necessary. This sets the destination for the **Open Dashboard** button when an operator investigates this specific alert on the [**Alerting**](/v1/docs/alerting-page) page (see [**Alert-Specific Actions**](/v1/docs/alerting-page#alertspecific-actions)).