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

# Change events

> Turn your deploy and change notifications into evidence investigations can use.

Most incidents are caused by a change: a deploy, a feature flag flip, a config push. Change events capture those changes as they happen, so an investigation can line them up against when your incident started and point at the one that likely caused it.

You don't connect anything separately for this. Change events are built automatically from the bot and automated messages already flowing through the [Slack channels you connect](/investigations/connect/slack): the deploy bot in your `#deploys` channel, the feature-flag notifications, the infrastructure alerts.

<Note>
  Change events are built from connected Slack channels, so they're available for Slack only. They aren't extracted from
  Microsoft Teams channels today.
</Note>

## How it works

When an automated message arrives in a channel you've connected, incident.io reads it and, if it describes a change, extracts a structured change event from it, pulling out what changed, when, who triggered it, and a link back to the source. A deploy notification becomes a deploy event with its service, environment, and commit; a feature-flag message becomes a flag event with the flag name.

During an investigation, these change events are correlated with the incident's timeline. A deploy that landed three minutes before the first error is exactly the kind of thing the investigation will surface, and because deploy events tie back to the underlying commit, it can connect that change to the specific code that shipped.

<Info>
  Only automated messages are turned into change events: the deploy bots, CI notifications, and flag-change alerts.
  Ordinary human discussion in the same channels is still used as [Slack context](/investigations/connect/slack), just
  not as change events.
</Info>

## What gets captured

Change events are sorted into categories so investigations can reason about them:

| Category           | Examples                                                 |
| ------------------ | -------------------------------------------------------- |
| **Deploy**         | A service or application being released                  |
| **Feature flag**   | A flag being turned on, off, or rolled out               |
| **Config**         | A configuration or settings change                       |
| **Infrastructure** | Changes to infrastructure, such as scaling or networking |
| **Database**       | Migrations and other database changes                    |
| **Alert**          | Automated alert notifications                            |
| **Other**          | Changes that don't fit the categories above              |

Each event also captures whatever detail the message contains: environment, service, commit, flag name, and a link back to the original notification.

## Setup

There's nothing extra to set up. Once you've connected the [Slack channels](/investigations/connect/slack) where your automated change notifications land, change events are extracted from them automatically.

<Tip>
  Connect the channels where your deploy, release, feature-flag, and infrastructure bots post. The more of your real
  change stream investigations can see, the more reliably they can trace an incident back to the change that caused it.
</Tip>

## Related

<CardGroup cols={2}>
  <Card title="Slack channels" icon="slack" href="/investigations/connect/slack">
    Connect the channels change events are built from.
  </Card>

  <Card title="Code repositories" icon="code" href="/investigations/connect/code/overview">
    Connect repositories so deploy events tie back to the code that shipped.
  </Card>
</CardGroup>