---
name: ContinuousDelivery-cd_at_events
title: Activity tracking events for Continuous Delivery
description: IBM Cloud® services, such as Continuous Delivery, generate activity tracking events.
last-updated: 2026-07-31
---

> ## Documentation Index
> The table of contents for this documentation set is at https://cloud.ibm.com/docs/ContinuousDelivery?format=markdown
> The index for all IBM Cloud docs is at: https://cloud.ibm.com/docs/llms.txt
> Use these files to discover more information as needed.

# Activity tracking events for Continuous Delivery
{: #at_events}

DevOps Insights will reach end of service and be discontinued on **August 31, 2026**. Continuous Delivery will be discontinued in the following regions on 12 February 2027: **au-syd**, **ca-mon**, **ca-tor**, **us-east**. Code Risk Analyzer will also be discontinued in all regions on that date. If a region has no active usage of these features, the features in that region may be discontinued earlier and stop accepting new instances. [Learn more](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-faq_region_feature_consolidation&format=markdown)
{: important}

IBM Cloud® services, such as Continuous Delivery, generate activity tracking events.
{: shortdesc}

Activity tracking events report on activities that change the state of a service in IBM Cloud. You can use the events to investigate abnormal activity and critical actions and to comply with regulatory audit requirements.

You can use IBM Cloud Activity Tracker Event Routing, a platform service, to route auditing events in your account to destinations of your choice by configuring targets and routes that define where activity tracking events are sent. For more information, see [About IBM Cloud Activity Tracker Event Routing](https://cloud.ibm.com/docs/atracker?topic=atracker-about&format=markdown).

You can use IBM Cloud Logs to visualize and alert on events that are generated in your account and routed by IBM Cloud Activity Tracker Event Routing to an IBM Cloud Logs instance.

## Locations where activity tracking events are generated
{: #at-locations}

Continuous Delivery sends activity tracking events from the regions that are indicated in the following table.

| Dallas (`us-south`) | Washington (`us-east`) | Toronto (`ca-tor`) | Montreal (`ca-mon`)  | Sao Paulo (`br-sao`) |
|---------------------|------------------------|--------------------|----------------------|----------------------|
| [Yes]{: tag-green}  | [Yes]{: tag-green}     | [Yes]{: tag-green} | [No]{: tag-red}   | [Yes]{: tag-green}   |
{: caption="Regions from which activity tracking events are sent in Americas locations" caption-side="top"}
{: #at-origins-table-1}
{: tab-title="Americas"}
{: tab-group="atorigins"}
{: class="simple-tab-table"}
{: row-headers}

| Tokyo (`jp-tok`)   | Sydney (`au-syd`)  |  Osaka (`jp-osa`)  | Chennai (`in-che`) |
|--------------------|--------------------|--------------------|--------------------|
| [Yes]{: tag-green} | [Yes]{: tag-green} | [No]{: tag-red} | [No]{: tag-red}    |
{: caption="Regions from which activity tracking events are sent in Asia Pacific locations" caption-side="top"}
{: #at-origins-table-2}
{: tab-title="Asia Pacific"}
{: tab-group="atorigins"}
{: class="simple-tab-table"}
{: row-headers}

| Frankfurt (`eu-de`) | London (`eu-gb`)   | Madrid (`eu-es`)   |
|---------------------|--------------------|--------------------|
| [Yes]{: tag-green}  | [Yes]{: tag-green} | [No]{: tag-red} |
{: caption="Regions from which activity tracking events are sent in Europe locations" caption-side="top"}
{: #at-origins-table-3}
{: tab-title="Europe"}
{: tab-group="atorigins"}
{: class="simple-tab-table"}
{: row-headers}

## Locations where activity tracking events are sent to IBM Cloud Activity Tracker hosted event search
{: #at-legacy-locations}

Continuous Delivery sends activity tracking events to IBM Cloud Activity Tracker hosted event search in the regions that are indicated in the following table.

| Dallas (`us-south`) | Washington (`us-east`) | Toronto (`ca-tor`) | Montreal (`ca-mon`)  | Sao Paulo (`br-sao`) |
|---------------------|------------------------|--------------------|----------------------|----------------------|
| [Yes]{: tag-green}  | [Yes]{: tag-green}     | [Yes]{: tag-green} | [No]{: tag-red}   | [Yes]{: tag-green}   |

{: caption="Regions where activity tracking events are sent in Americas locations" caption-side="top"}
{: #at-table-1}
{: tab-title="Americas"}
{: tab-group="at"}
{: class="simple-tab-table"}
{: row-headers}

| Tokyo (`jp-tok`)   | Sydney (`au-syd`)  |  Osaka (`jp-osa`)  | Chennai (`in-che`) |
|--------------------|--------------------|--------------------|--------------------|
| [Yes]{: tag-green} | [Yes]{: tag-green} | [No]{: tag-red} | [No]{: tag-red}    |
{: caption="Regions where activity tracking events are sent in Asia Pacific locations" caption-side="top"}
{: #at-table-2}
{: tab-title="Asia Pacific"}
{: tab-group="at"}
{: class="simple-tab-table"}
{: row-headers}

| Frankfurt (`eu-de`) | London (`eu-gb`)   | Madrid (`eu-es`)   |
|---------------------|--------------------|--------------------|
| [Yes]{: tag-green}  | [Yes]{: tag-green} | [No]{: tag-red} |
{: caption="Regions where activity tracking events are sent in Europe locations" caption-side="top"}
{: #at-table-3}
{: tab-title="Europe"}
{: tab-group="at"}
{: class="simple-tab-table"}
{: row-headers}

## Locations where activity tracking events are sent by IBM Cloud Activity Tracker Event Routing
{: #atracker-locations}

Continuous Delivery sends activity tracking events by IBM Cloud Activity Tracker Event Routing in the regions that are indicated in the following table.

| Dallas (`us-south`) | Washington (`us-east`) | Toronto (`ca-tor`) | Montreal (`ca-mon`)  | Sao Paulo (`br-sao`) |
|---------------------|------------------------|--------------------|----------------------|----------------------|
| [Yes]{: tag-green}  | [Yes]{: tag-green}     | [Yes]{: tag-green} | [No]{: tag-red}   | [Yes]{: tag-green}   |
{: caption="Regions where activity tracking events are sent in Americas locations" caption-side="top"}
{: #atracker-table-1}
{: tab-title="Americas"}
{: tab-group="atracker"}
{: class="simple-tab-table"}
{: row-headers}

| Tokyo (`jp-tok`)   | Sydney (`au-syd`)  |  Osaka (`jp-osa`)  | Chennai (`in-che`) |
|--------------------|--------------------|--------------------|--------------------|
| [Yes]{: tag-green} | [Yes]{: tag-green} | [No]{: tag-red} | [No]{: tag-red}    |
{: caption="Regions where activity tracking events are sent in Asia Pacific locations" caption-side="top"}
{: #atracker-table-2}
{: tab-title="Asia Pacific"}
{: tab-group="atracker"}
{: class="simple-tab-table"}
{: row-headers}

| Frankfurt (`eu-de`) | London (`eu-gb`)   | Madrid (`eu-es`)   |
|---------------------|--------------------|--------------------|
| [Yes]{: tag-green}  | [Yes]{: tag-green} | [No]{: tag-red} |
{: caption="Regions where activity tracking events are sent in Europe locations" caption-side="top"}
{: #atracker-table-3}
{: tab-title="Europe"}
{: tab-group="atracker"}
{: class="simple-tab-table"}
{: row-headers}

## Viewing activity tracking events for Continuous Delivery
{: #at-viewing}

You can use IBM Cloud Logs to visualize and alert on events that are generated in your account and routed by IBM Cloud Activity Tracker Event Routing to an IBM Cloud Logs instance.

Continuous Delivery in a region sends activity tracking events by IBM Cloud Activity Tracker Event Routing in the same region.

### Launching IBM Cloud Logs from the Observability page
{: #log-launch-standalone}

For information on launching the IBM Cloud Logs UI, see [Launching the UI in the IBM Cloud Logs documentation.](https://cloud.ibm.com/docs/cloud-logs?topic=cloud-logs-instance-launch&format=markdown)

## List of platform events
{: #at_actions_platform}

The following table lists the activity tracking event actions that the IBM Cloud platform generates when Continuous Delivery instances are processed.

| Action                                          | Description |
|-------------------------------------------------|-------------|
| `continuous-delivery.instance.create`           | An event is generated when you provision a service instance. |
| `continuous-delivery.instance.update`           | An event is generated when you rename a service instance or when you change the service plan. |
| `continuous-delivery.instance.delete`           | An event is generated when a service instance is deleted. |
| `continuous-delivery.instance.schedule_reclaim` | An event is generated when a service instance is pending_reclamation. |
| `continuous-delivery.instance.restore`          | An event is generated when a service instance is restored. |
{: caption="Actions that generate platform events" caption-side="bottom"}

The following table lists the actions that generate an event for managing service credentials that are associated with a service instance.

| Action                           | Description |
|----------------------------------|-------------|
| `continuous-delivery.key.create` | An event is generated when an API key is created for a service instance through the *Service credentials* section of the service instance UI. |
| `continuous-delivery.key.delete` | An event is generated when an API key that is associated with a service instance is deleted from the *Service credentials* section of the service instance UI. |
{: caption="Actions that generate service credentials events" caption-side="bottom"}

## Events for Continuous Delivery
{: #at_actions_cd}

The following table lists the actions that generate Continuous Delivery management and data events:

| Action                           | Description                        |
|----------------------------------|------------------------------------|
| `continuous-delivery.settings.read` | View the settings of a Continuous Delivery service instance. |
| `continuous-delivery.settings.update` | Update the settings of a Continuous Delivery service instance. |
{: caption="Lists of management events for Continuous Delivery" caption-side="bottom"}
{: #componentcd-table-1}
{: tab-title="Management events"}
{: tab-group="componentcd"}
{: class="simple-tab-table"}
{: row-headers}

| Action                           | Description                        |
|----------------------------------|------------------------------------|
| `continuous-delivery.auth-user.create` | Manually or automatically add authorized users. For more information about automatically adding authorized users, see [How are users counted for instances of Continuous Delivery in resource groups?](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-limitations_usage&interface=ui&format=markdown#count_users_rg). |
| `continuous-delivery.auth-user.read` | View the list of authorized users from the Manage tab of a Continuous Delivery service instance. |
| `continuous-delivery.auth-user.delete` | Delete authorized users from the Continuous Delivery service instance. |
| `continuous-delivery.consolidated-auth-users.list` | View the list of consolidated authorized users from the Manage tab of a Continuous Delivery service instance. |
{: caption="Lists of data events for Continuous Delivery" caption-side="bottom"}
{: #componentcd-table-2}
{: tab-title="Data events"}
{: tab-group="componentcd"}
{: class="simple-tab-table"}
{: row-headers}

## Events for toolchains
{: #at_actions_toolchain}

The following table lists the actions that generate toolchain management and data events:

| Action                           | Description                        |
|----------------------------------|------------------------------------|
| `toolchain.instance.create` | Create a toolchain |
| `toolchain.instance.update` | Rename a toolchain. This event is not sent when tool integrations are added to (`toolchain.tool-instance.deploy`) or removed from (`toolchain.tool-instance.undeploy`) a toolchain. If the toolchain is secured by a customer root key in a professional plan, the event contains the root key identifier. |
| `toolchain.instance.delete` | Delete a toolchain. |
| `toolchain.tool-instance.deploy` | Add a tool integration to a toolchain. |
| `toolchain.tool-instance.undeploy` | Remove a tool integration from a toolchain. |
| `toolchain.instance-key-state.update` | Update the root key in the key management service (KMS) provider that the toolchain uses. For example, enable, disable, or rotate a root key in a KMS provider. |
| `toolchain.instance.unwrap` | Unwrap a wrapped Data Encryption Key (wDEK) in order to encrypt or decrypt customer personal information. |
{: caption="Lists of management events for toolchains" caption-side="bottom"}
{: #componenttc-table-1}
{: tab-title="Management events"}
{: tab-group="componenttc"}
{: class="simple-tab-table"}
{: row-headers}

| Action                           | Description                        |
|----------------------------------|------------------------------------|
| `toolchain.event.send` | Send a client bespoke toolchain event. The event metadata includes the bespoke toolchain event's `title` and `description` values. |
| `toolchain.tool-instance.create` | Add a tool integration to a toolchain. This event is always followed by the toolchain.tool-instance.deploy event. |
| `toolchain.tool-instance.read` | View the configuration of a tool integration. |
| `toolchain.tool-instance.update` | Save configuration changes to a tool integration. |
| `toolchain.tool-instance.delete` | Remove a tool integration from a toolchain. This event is always preceded by the toolchain.tool-instance.undeploy event. |
{: caption="Lists of data events for toolchains" caption-side="bottom"}
{: #componenttc-table-2}
{: tab-title="Data events"}
{: tab-group="componenttc"}
{: class="simple-tab-table"}
{: row-headers}


Activity tracking events are different from client bespoke toolchain events. When you invoke the [POST /toolchains/{toolchain_id}/events](https://cloud.ibm.com/apis/toolchain#create-toolchain-event){: external} API to send a bespoke toolchain event, the toolchain sends a notification event to any instances of Event Notifications that are integrated into the toolchain. In addition, the toolchain sends an activity tracking event that serves as a record of the API having been invoked. {: tip}

## Events for DevOps Insights
{: #at_actions_insights}

The following table lists the actions that generate DevOps Insights management and data events:

| Action                           | Description                        |
|----------------------------------|------------------------------------|
| `toolchain.insights-tag.create` | Create a tag. |
| `toolchain.insights-tag.read` | View a tag. |
| `toolchain.insights-tag.update` | Update a tag. |
| `toolchain.insights-tag.delete` | Delete a tag. |
| `toolchain.insights-decision.evaluate` | Make a gate decision on a build. |
{: caption="Lists of management events for DevOps Insights" caption-side="bottom"}
{: #componentdra-table-1}
{: tab-title="Management events"}
{: tab-group="componentdra"}
{: class="simple-tab-table"}
{: row-headers}

| Action                           | Description                        |
|----------------------------------|------------------------------------|
| `toolchain.insights.read` | View any build, deploy, or test record. |
| `toolchain.insights.update` | Publish a new build, deploy, or test record. The event's metadata includes `toolchainId` (unique identifier for toolchain) and might also contain the `build_artifact` (name of application), `build_id` (id of build), `branch` (Git branch of build), `environment_name` (name of environment where the test ran), and `operationId` (indicates how the update was completed, such as `postBuild`, `postResults`, `postDeployment`, `postResultsById`, `postLifeCycleStage`, `postBuildArtifactMetaData`, `putLifeCycleStage`, `putLifeCycleStagesOrder`, and `resultsMultipart`) values. The values that are included in the event's metadata is determined by the type of record (build, deployment, or test) that is published. |
| `toolchain.insights-policy.create` | Create a policy. |
| `toolchain.insights-policy.read` | View a policy. |
| `toolchain.insights-policy.update` | Update a policy. The event's metadata might include the `toolchainId` (unique identifier for toolchain) and `policyName` (name of policy that was updated) values. |
| `toolchain.insights-policy.delete` | Delete a policy. |
| `toolchain.insights-data-toolchain.delete` | Delete data for a toolchain. |
| `toolchain.insights-data-environment.delete` | Delete data for a specific environment. |
| `toolchain.insights-data-application.delete` | Delete data for a specific application. |
| `toolchain.insights-data-branch.delete` | Delete data for a specific application and branch. |
{: caption="Lists of data events for DevOps Insights" caption-side="bottom"}
{: #componentdra-table-2}
{: tab-title="Data events"}
{: tab-group="componentdra"}
{: class="simple-tab-table"}
{: row-headers}

## Events for component Delivery Pipeline
{: #at_actions_pipeline}

The following table lists the actions that generate Delivery Pipeline management and data events:

| Action                           | Description                        |
|----------------------------------|------------------------------------|
| `toolchain.pipeline.create` | Create a Classic delivery pipeline or a Tekton delivery pipeline for a toolchain. |
| `toolchain.pipeline-run.create` | Trigger a Classic delivery pipeline or a Tekton delivery pipeline to either run manually, at a scheduled time, when a specified Git event occurs, or by way of a POST request to the generic webhook URL. |
{: caption="Lists of management events for Delivery Pipeline" caption-side="bottom"}
{: #componentdp-table-1}
{: tab-title="Management events"}
{: tab-group="componentdp"}
{: class="simple-tab-table"}
{: row-headers}

| Action                           | Description                        |
|----------------------------------|------------------------------------|
| `toolchain.pipeline.read` | View the delivery pipeline or the Tekton pipeline from a  Continuous Delivery service instance. |
| `toolchain.pipeline.update` | Rename the delivery pipeline or a Tekton pipeline. Update pipeline properties. Add, edit, or delete stages. This event is triggered by a change to a tool integration configuration. Because the customer data that is included in a typical update might contain secret data, job scripts, and more, this event does not include the `InitialValue` and `newValue` values. |
| `toolchain.pipeline.delete` | Delete the delivery pipeline or Tekton pipeline from the Continuous Delivery toolchain instance  |
| `toolchain.pipeline-run.read` | View the run logs for a delivery pipeline or a Tekton pipeline in the Tekton dashboard. |
| `toolchain.pipeline-run.update` | Update the delivery pipeline when a job completes within a stage or a user cancels a stage. Because the customer data that is included in a typical update might contain secret data, log output, large data, and more, this event does not include the `InitialValue` and `newValue` values. |
| `toolchain.pipeline-run.delete` | Delete the delivery pipeline when a pipeline job run is deleted by the Continuous Delivery service. The delivery pipeline retains a limited number of runs.  |
{: caption="Lists of data events for Delivery Pipeline" caption-side="bottom"}
{: #componentdp-table-2}
{: tab-title="Data events"}
{: tab-group="componentdp"}
{: class="simple-tab-table"}
{: row-headers}

## Analyzing Continuous Delivery activity tracking events
{: #at_events_cd_analyze}

When user emails are added to or removed from the authorized users list of a Continuous Delivery service instance in a resource group, Continuous Delivery sends events to IBM Cloud Activity Tracker Event Routing when either of the following methods are used.

* An administrator manually adds or removes a user email from the **Manage** tab of the Continuous Delivery service.
* The system automatically adds one or more user emails in response to user-initiated or service-initiated actions with Continuous Delivery toolchains.

The following authorized user events are sent to IBM Cloud Activity Tracker Event Routing:

* `Continuous Delivery: create auth-user [service name] (auth-user(s): [EMAILS])`
* `Continuous Delivery: delete auth-user [service name] (auth-user(s): [EMAILS])`
* `Continuous Delivery: create auth-user [service name] (auth-user(s): [EMAILS]; root-action: [ACTION]; root-action-service-instance: [CRN])`
* `Continuous Delivery: delete auth-user [service name] (auth-user(s): [EMAILS]; root-action: [ACTION]; root-action-service-instance: [CRN])`

where:

* `[EMAILS]` is a comma-separated list of the user email IDs that are added to or removed from the list of authorized users.
* `[ACTION]` identifies the action that prompted the automatic addition or removal of user emails from the list of authorized users. If a root-action is not specified, the addition or removal of the user emails was performed directly by a user from the **Manage** tab of the Continuous Delivery service dashboard.
* `[CRN]` specifies the [Cloud Resource Name](https://cloud.ibm.com/docs/account?topic=account-crn&format=markdown) of the resource to which the root-action was applied. This resource can either be a toolchain or the Continuous Delivery service instance itself.

The following table lists and describes the root actions that prompt user emails to automatically be added to or removed from the authorized users list.

| Root action | Description |
|:-----------------|:-----------------|
| `continuous-delivery.instance.create` | Add a user email when the Continuous Delivery service is provisioned. This email belongs to the user who created the service instance. The `root-action-service-instance` CRN identifies the Continuous Delivery service instance. |
| `continuous-delivery.instance.delete` | Remove user emails when the Continuous Delivery service is de-provisioned. The `root-action-service-instance` CRN identifies the Continuous Delivery service instance. |
| `toolchain.git-repos-and-issue-tracking-repo.evaluate` | Add user emails after system evaluation of a Git Repos and Issue Tracking repo. Multiple emails that correspond to users with Developer (or greater) access to the repo might be added. The `root-action-service-instance` CRN identifies the toolchain that contains the Git Repos and Issue Tracking tool integration. |
| `toolchain.pipeline-stage.start` | Add user emails when a delivery pipeline stage starts. If the pipeline stage is manually started, the email of the user who started the pipeline is added. If a pipeline stage is triggered by a change to a repository (repo) in the Git Repos and Issue Tracking tool integration, multiple emails that correspond to users with Developer (or greater) access to the repo might be added. The `root-action-service-instance` CRN identifies the toolchain that contains the pipeline. |
| `toolchain.pipeline.read` | Add a user email when the user views a delivery pipeline. The `root-action-service-instance` CRN identifies the toolchain that contains the pipeline. |
| `toolchain.pipeline.update` | Add a user email when the user edits a delivery pipeline. The `root-action-service-instance` CRN identifies the toolchain that contains the pipeline. |
{: caption="Actions that add or remove user emails from the authorized users list" caption-side="top"}