> For the complete documentation index, see [llms.txt](https://docs.ilert.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ilert.com/alerting/deployment-events.md). # Deployment events Most incidents are caused by a change. A responder's first question is almost always *what changed just now*, and answering it usually means leaving ilert for a CI dashboard, a release channel, or a colleague. Deployment events remove that hop. Your CI/CD tooling reports what it shipped, ilert matches those reports against alerts as they fire, and the alert opens with the likely culprits already attached. The receiving object is a **deployment pipeline**. It is to deployment events what an alert source is to alerts: it holds the integration key, and events are routed by it. See [Deployment integrations](/integrations/deployment-integrations.md) to set one up. Every plan includes deployment events. Find them in the sidebar under **Alerting** → **Deployment events**. ## What counts as a deployment Deployment events are built for CI/CD, but nothing in them is specific to software. A pipeline records timestamped facts and correlates them with alerts, so anything that changes the state of a system and might explain an alert twenty minutes later belongs here: * a campaign going live * a product launch or a price list being published * goods moving through a supply chain * a course opening for enrollment * a regulatory or compliance release * content being published If it can break something, it is worth having on the alert. ## How correlation works When an alert is created, ilert attaches **at most three** deployments to it, chosen one of two ways. ### Team-owned pipelines take precedence ilert first works out which teams the alert belongs to: the teams that own its **escalation policy**, and then the teams that own its **alert source**. If any deployment pipeline is owned by one of those teams, only that team's pipelines are considered, and the deployments it attaches carry the reason *This deployment occurred … on the same team to which this alert belongs to*. This is the mechanism a team uses to claim its own deployments. Assign the pipeline to the same team that owns the escalation policy, and its alerts stop being matched against everyone else's releases — without an administrator changing anything centrally. ### Otherwise, recent deployments account-wide If no pipeline is owned by any of the alert's teams, ilert falls back to time alone: deployments from anywhere in the account, in the **two hours** before the alert was reported, with the reason *This alert occurred … after this deployment*. That is the fast start. One organization-wide webhook into one pipeline begins producing correlations immediately, with no team structure required, and for a small account it may be all you ever need. {% hint style="info" %} The two modes are exclusive, per alert, and the switch is automatic. The moment a team owns a pipeline, its alerts stop seeing account-wide deployments — so a half-finished migration where one team has a pipeline and another does not still leaves both with sensible results. {% endhint %} ## Scaling to a larger account The account-wide window works because a small account deploys rarely enough that "in the last two hours" is a short list. At a hundred deployments a day it stops meaning anything: everything correlates with everything. The way out is not a central configuration. It is for each team to set up a pipeline against its own repositories and assign it to itself — the same team that owns its escalation policies and alert sources. Each team's alerts then draw only on that team's deployments, and teams that have not migrated yet keep the account-wide behavior in the meantime. ## Related {% content-ref url="/pages/d03jP9Bn0M0ywWLe3Ad9" %} [Deployment integrations](/integrations/deployment-integrations.md) {% endcontent-ref %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.ilert.com/alerting/deployment-events.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.