> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/continuous-delivery/use-continuous-delivery/verify-deployments/configure-cv/verify-deployments.md).
# Configure the AI Verify (v1) Step
Add and configure the AI Verify (v1) step to verify deployments with health sources
{% hint style="info" %}
This feature is in Beta[^1] and requires enablement. [View all early access features.](/release-notes/features.md)
{% @harness-feature-flag-access/request-feature-flag-access module="continuous-delivery" pagePath="continuous-delivery/use-continuous-delivery/verify-deployments/configure-cv/verify-deployments" featureFlags="%5B%7B%22name%22%3A%22AI%20Verify%20configurable%20properties%22%2C%22key%22%3A%22CDS\_CV\_INPUT\_OUTPUT\_VARIABLES\_ENABLED%22%2C%22status%22%3A%22BETA%22%2C%22description%22%3A%22Enables%20configurable%20properties%20on%20the%20AI%20Verify%20(v1)%20step%20so%20you%20can%20customize%20verification%20behavior%20and%20pass%20verification%20results%20to%20later%20steps.%22%7D%2C%7B%22name%22%3A%22AI%20Verify%20sub-task%20webhook%20notifications%22%2C%22key%22%3A%22CDS\_CV\_SUB\_TASK\_CUSTOM\_WEBHOOK\_NOTIFICATIONS\_ENABLED%22%2C%22status%22%3A%22BETA%22%2C%22description%22%3A%22Enables%20custom%20webhook%20notifications%20for%20verification%20sub-tasks%20such%20as%20data%20collection%2C%20log%20analysis%2C%20and%20time%20series%20analysis.%22%7D%2C%7B%22name%22%3A%22Pinned%20baseline%20verification%22%2C%22key%22%3A%22SRM\_ENABLE\_BASELINE\_BASED\_VERIFICATION%22%2C%22status%22%3A%22BETA%22%2C%22description%22%3A%22Enables%20pinning%20a%20successful%20verification%20as%20a%20baseline%20for%20future%20Load%20Testing%20verification%20runs.%22%7D%5D" %}
{% endhint %}
Continuous Verification integrates with [health sources](/continuous-delivery/use-continuous-delivery/verify-deployments/configure-cv/health-sources.md) to verify that the deployed service is running safely, support automatic rollbacks, and apply machine learning to deployments so anomalies can be flagged in later runs.
This topic covers how to add and configure health sources for the AI Verify (v1) step.
***
## What you will learn from this topic
* How to [add the AI Verify (v1) step](#add-the-ai-verify-v1-step) during strategy selection or to an existing Execution
* How to [create a monitored service](#create-a-monitored-service) and [add health sources](#add-health-sources)
* How to set [sensitivity](#select-sensitivity), [duration](#select-duration), and optional [configurable properties](#configurable-properties)
* How to enable [sub-task webhook notifications](#sub-task-notifications) and [pin a baseline](#set-a-pinned-baseline)
***
## Before you begin
Confirm the following before you configure the AI Verify (v1) step:
* **Deploy stage**: A Continuous Delivery Deploy stage with a service, environment, and execution strategy.
* **Health source access**: Connectors and credentials for the APM or logging tool you will use. Go to [health sources](/continuous-delivery/use-continuous-delivery/verify-deployments/configure-cv/health-sources.md) to review supported sources.
* **Monitored service concept**: A monitored service maps a Harness service to a service monitored by your APM or logging tool. Go to [Monitored Service](https://developer.harness.io/docs/platform/use-harness-platform/monitored-service) to review the Platform entity.
* **Continuous Verification types**: Match the verification type to your deployment strategy. Go to [Continuous Verification type](/continuous-delivery/use-continuous-delivery/verify-deployments/verify-deployments-with-the-verify-step.md#continuous-verification-type) for type definitions.
***
## Verification setup options
To use the AI Verify (v1) step, you need a Harness monitored service. You can set up a monitored service in the AI Verify (v1) step in a Deploy stage.
There are other ways to set up a monitored service. Go to [Monitored Service](https://developer.harness.io/docs/platform/use-harness-platform/monitored-service) to review those options.
This topic sets up the monitored service as part of the **AI Verify (v1)** step.
***
## Add the AI Verify (v1) step
There are two ways to add the AI Verify (v1) step.
### Add during strategy selection
Perform the following steps when you select the stage deployment strategy for the first time:
1. Open the **Execution** settings and select the deployment strategy.
2. Select **Enable Verification**.
3. Harness adds the **Verify** step automatically. For example, the following image shows a stage where the Canary strategy and **Enable Verification** were selected.
### Add to an existing Execution
You can also add the AI Verify (v1) step to the Execution section of a Deploy stage in a pipeline you previously created.
1. Click **Add Step** after the deployment step.
2. Select **Verify**.
***
## Enter a name and timeout
In **Name**, enter a name for the step.
In **Timeout**, enter a timeout value for the step.
You can use the following units:
* `w` for weeks
* `d` for days
* `h` for hours
* `m` for minutes
* `s` for seconds
* `ms` for milliseconds
The maximum is `53w`. Timeouts can also be set at the pipeline level.
***
## Select a Continuous Verification type
In **Continuous Verification Type**, select a type that matches your [deployment strategy](/continuous-delivery/use-continuous-delivery/verify-deployments/verify-deployments-with-the-verify-step.md#continuous-verification-type).
***
## Create a monitored service
In **Monitored Service**, click **Click to autocreate a monitored service**.
Harness creates a monitored service using a concatenation of the service and environment names. For example, a service named `todolist` and an environment named `dev` results in a monitored service named `todolist_dev`.
{% hint style="info" %}
**GitX for monitored services**
Monitored services can be stored in Git repositories using GitX, which enables version control and feature branch support for verification configurations. Go to [Store monitored services in Git](https://developer.harness.io/docs/platform/use-harness-platform/git-experience/gitx-monitored-services) to configure GitX for monitored services.
{% endhint %}
{% hint style="info" %}
**Runtime service or environment values**
The option to auto-create a monitored service is not available if you have configured either a service, an environment, or both as runtime values. When you run the pipeline, Harness concatenates the service and environment values you enter on the runtime inputs screen and generates a monitored service name. If a monitored service with the same name exists, Harness assigns it to the pipeline. If no monitored service matches the generated name, Harness skips the verification step.
For example, if you enter the service as `todolist` and the environment as `dev`, Harness generates the monitored service name `todolist_dev`, checks whether that monitored service exists, and assigns it to the pipeline when it does. If it does not exist, Harness skips the verification step.
{% endhint %}
***
## Add health sources
Harness supports a wide variety of health sources. For the full list and setup instructions for each source, go to [health sources](/continuous-delivery/use-continuous-delivery/verify-deployments/configure-cv/health-sources.md).
***
## Select sensitivity
In **Sensitivity**, select **High**, **Medium**, or **Low** based on the risk level used as failure criteria during the deployment.
***
## Select duration
Select how long you want Harness to analyze and monitor the logs and APM data points. Harness waits for 2-3 minutes to allow enough time for the data to be sent to the APM or logging tool before it analyzes the data. This wait time is standard with monitoring tools.
The recommended **Duration** is **10 min** for logging providers and **15 min** for APM and infrastructure providers.
***
## Configurable properties
The AI Verify (v1) step supports configurable properties that let you customize verification behavior and access verification results in subsequent pipeline steps. This capability is controlled by the feature flag `CDS_CV_INPUT_OUTPUT_VARIABLES_ENABLED`. Contact [Harness Support](mailto:support@harness.io) if the option is not available in your account.
To add a configurable property, perform the following steps:
1. In the AI Verify (v1) step configuration, expand the **Optional** section.
2. Under **Configurable Properties**, select a property from the dropdown.
3. Enter the value for the selected property.
### deploymentStartTime
Use `deploymentStartTime` to specify when the deployment started. This tells Harness where to anchor the verification window, so the system can collect pre-deployment baseline data for the configured duration before this time. Enter the timestamp in UTC using one of the following formats:
* ISO 8601 (for example, `2023-03-10T15:30:00Z`)
* Common date/time format (for example, `2023-03-10 15:30:00`)
* Unix epoch timestamps (for example, `1678457400`)
You can also use a pipeline expression to set the value dynamically. For example, `<+pipeline.stages.stage_name.spec.execution.steps.step_name.startTs>` resolves to the start timestamp of another step in your pipeline.
Timestamps that have not been reached when the step runs are not supported as fixed or runtime values. If you specify a time that has not been reached when the step runs, verification fails. If the specified time has already passed when the step executes, it is used as expected.
### dataCollectionDuration
Use `dataCollectionDuration` to override the default data collection interval for the verification window. Enter the value as a positive integer representing the number of minutes. The maximum allowed value is 60 minutes.
### customVerificationStartTime
By default, the post-deployment data collection window opens at the moment Harness executes the AI Verify (v1) step. Deploy stage deployment steps wait for a steady state before completing, which means the AI Verify (v1) step starts after a delay from when your service began running. During that delay, your health source may already be recording logs and metrics that fall outside the collection window.
Use `customVerificationStartTime` to shift the window start to an earlier timestamp so that data already recorded by your health source is included in the analysis. Enter a timestamp using any of the formats listed under `deploymentStartTime`. The value must be no earlier than the deployment start time.
If the custom time is earlier than the actual verification start time, Harness uses it as the window start. If the custom time is later than the actual verification start time, Harness ignores it, falls back to the actual verification start time, and logs a warning in the execution console.
For verification durations under 30 minutes, Harness buckets data in one-minute intervals, so a custom start time that falls earlier within a minute expands the collection window by one full minute.
Common use cases for this property include:
* **Capturing head-of-deployment logs**: If your health source (for example, Dynatrace) begins recording immediately when the service starts, set `customVerificationStartTime` to the deployment step start time to avoid missing the earliest entries.
* **Steps between deployment and verification**: If you have additional steps between your deployment step and the AI Verify (v1) step, metrics and logs generated while those steps run are normally excluded from verification. Setting this property to the deployment step start time includes that data.
***
## Sub-task notifications
Sub-task webhook notifications are controlled by the feature flag `CDS_CV_SUB_TASK_CUSTOM_WEBHOOK_NOTIFICATIONS_ENABLED`. Contact [Harness Support](mailto:support@harness.io) if the option is not available in your account.
Harness can send detailed webhook notifications for verification sub-tasks, so you can track the progress and results of individual verification operations such as data collection, log analysis, and time series analysis. This enables fine-grained monitoring and integration with external systems.
### Enable sub-task notifications
To configure custom webhook notifications for verification sub-tasks, perform the following steps:
1. In the AI Verify (v1) step configuration, expand the **Optional** section.
2. Select the **Enable custom webhook notification** checkbox.
3. Enter the **URL to be called** for the webhook endpoint.
4. (Optional) Add custom headers by clicking **+ Add Headers** and providing name-value pairs.
The following YAML shows a configuration example:
```yaml
isCustomWebhookNotificationEnabled: true
customWebhookNotification:
notificationDeliveryMode: PLATFORM
webhookUrl: https://your-webhook-endpoint.com/path
headers:
- key: X-Custom-Header
value: your-header-value
```
### Notification delivery options
You can choose how notifications are delivered:
* **Platform** (default): Notifications are sent through the Harness platform.
* **Delegate**: Notifications are sent through a Harness Delegate. When using delegate delivery, you can optionally specify delegate selectors to control which delegates handle the webhook calls.
### Notification event types
When enabled, Harness sends webhook notifications for the following verification sub-task events.
**Data Collection Task**
Sent for data collection task status for a verification window.
Sample payload
```json
{
"eventData": {
"verificationJobInstanceId": "your_verification_job_instance_id",
"lastPickedAt": "2026-01-05T08:34:19.108Z",
"verificationTaskId": "your_verification_task_id",
"lastUpdatedAt": "1767602059813",
"retryCount": "1",
"eventType": "DataCollectionTask",
"analysisEndTime": "2026-01-05T08:32:00Z",
"notificationTimestamp": "1767602059827",
"createdAt": "1767601849955",
"startTime": "2026-01-05T08:31:00Z",
"endTime": "2026-01-05T08:32:00Z",
"firstPickedAt": "2026-01-05T08:34:19.108Z",
"planExecutionId": "your_plan_execution_id",
"status": "SUCCESS",
"analysisStartTime": "2026-01-05T08:31:00Z"
}
}
```
**Deployment Time Series Analysis**
Sent when time series (metric) analysis completes for a verification window.
Sample payload
```json
{
"eventData": {
"verificationJobInstanceId": "your_verification_job_instance_id",
"createdAt": "1767602082711",
"verificationTaskId": "your_verification_task_id",
"lastUpdatedAt": "1767602082711",
"startTime": "2026-01-05T08:31:00Z",
"endTime": "2026-01-05T08:32:00Z",
"eventType": "DeploymentTimeSeriesAnalysis",
"planExecutionId": "your_plan_execution_id",
"notificationTimestamp": "1767602082723"
}
}
```
**Verification Terminal State**
Sent when the verification step reaches a terminal state.
Sample payload
```json
{
"eventData": {
"verificationJobInstanceId": "your_verification_job_instance_id",
"isFinal": "true",
"eventType": "VerificationTerminalState",
"planExecutionId": "your_plan_execution_id",
"status": "VERIFICATION_PASSED",
"actualRunDuration": "489",
"notificationTimestamp": "1767602326817"
}
}
```
### Payload field descriptions
The following fields help you correlate related notifications for a single verification execution:
* `verificationJobInstanceId`: Unique identifier for the verification job instance
* `planExecutionId`: Pipeline execution identifier
* `verificationTaskId`: Unique identifier for the verification task
{% hint style="info" %}
**Multiple verification tasks**
There can be multiple `verificationTaskId` values correlated with a single `verificationJobInstanceId`.
{% endhint %}
Use these fields to correlate and group related notifications for a single verification execution.
Event types include:
* `DataCollectionTask`: Data collection completed
* `DeploymentLogAnalysis`: Logs analysis completed
* `DeploymentTimeSeriesAnalysis`: Metric analysis completed
* `VerificationTerminalState`: Final verification result
For a typical 5-minute verification step, you can expect multiple webhook notifications as sub-tasks progress, with analysis notifications, then data collection notifications, then a terminal notification with final status.
### Test webhook configuration
After configuring your webhook URL and headers, click **Test** to send a sample notification to your webhook endpoint. This helps verify that your endpoint is configured to receive and process the notifications.
***
## Specify artifact tag
In **Artifact Tag**, use a [Harness expression](https://developer.harness.io/docs/platform/use-harness-platform/variables-and-expressions/harness-variables).
The expression `<+serviceConfig.artifacts.primary.tag>` refers to the primary artifact.
***
## Advanced settings
In **Advanced**, you can select the following options:
* [Step skip condition settings](https://developer.harness.io/docs/platform/use-harness-platform/pipelines/step-skip-condition-settings)
* [Step failure strategy settings](https://developer.harness.io/docs/platform/use-harness-platform/pipelines/failure-handling/define-a-failure-strategy-on-stages-and-steps)
* [Select delegates with selectors](https://developer.harness.io/docs/platform/use-harness-platform/delegates/delegate/manage-delegates/select-delegates-with-selectors)
***
## Deploy and review results
After setting up the **Verify** step, click **Apply Changes**.
Click **Run** to run the pipeline.
In **Run Pipeline**, select the tag for the artifact if a tag was not added in the **Artifact Details** settings.
Click **Run Pipeline**.
When the pipeline is running, click the **Verify** step.
Verification can take a few minutes.
Once verification is complete, the AI Verify (v1) step shows results similar to the following:
The risk level might initially display a number of violations, but the red and orange colored host often change to green over the duration.
### Summary
The **Summary** section shows the number of logs that are in violation.
### Console View
Click **Console View** or click **View Details** in **Summary** to inspect verification in more detail.
You can use the search option to search for any specific metric or transaction you want.
***
## Set a pinned baseline
Pinned baseline verification is controlled by the feature flag `SRM_ENABLE_BASELINE_BASED_VERIFICATION`. Contact [Harness Support](mailto:support@harness.io) if the option is not available in your account.
You can set a specific verification in a successful pipeline execution as a baseline. This is available with **Load Testing** as the verification type.
### Set successful verification as a baseline
To set a verification as the baseline for future verifications, perform the following steps:
1. In Harness, go to **Deployments** -> **Pipelines**, and find the pipeline you want to use as the baseline.
2. Select the successful pipeline execution with the verification that you want to use as the baseline. The pipeline execution is displayed.
3. On the pipeline execution, go to the **Verify** section, then select **Pin baseline**.
The selected verification is set as the baseline for future verifications.
### Replace an existing pinned baseline
To use a new baseline from a pipeline and replace the existing pinned baseline, perform the following steps:
1. In Harness, go to **Deployments** -> **Pipelines**, and find the pipeline from which you want to remove the baseline.
2. Select the successful pipeline execution with the verification that you previously pinned as the baseline.
3. On the pipeline execution, go to the **Verify** section, then select **Pin baseline**.
A confirmation alert message appears, asking if you want to replace the existing pinned baseline with the current verification. After you confirm, the existing pinned baseline is replaced with the current verification.
***
## Next steps
* [Health sources](/continuous-delivery/use-continuous-delivery/verify-deployments/configure-cv/health-sources.md): Configure APM and logging health sources for verification.
* [Verify deployments with the Verify step](/continuous-delivery/use-continuous-delivery/verify-deployments/verify-deployments-with-the-verify-step.md): Review Continuous Verification types and related AI Verify (v1) concepts.
* [Monitored Service](https://developer.harness.io/docs/platform/use-harness-platform/monitored-service): Manage monitored services in the Harness Platform.
{% @harness-feedback/feedback %}
[^1]: Beta features are feature-complete but still being validated. Available on request.