Deploy previews

Netlify builds a preview site for each branch or pull request. An agent watches the deploy event, reads the build outcome and the preview URL, and posts that link to the review channel your team chose. When a preview build fails, it reads the error summary from the log and notifies the assigned engineer with the failing step named. Previews that succeed cleanly are announced without interruption. Anything the agent cannot classify from the log, an ambiguous timeout or a partial deploy, is escalated to a person rather than reported as passing or failing.

Build status alerts

Every Netlify deploy moves through queued, building, and published states. An agent reads the status of a triggered build and applies the notification rule your team approved, quietly confirming routine successes and raising failures where people will see them. It records which commit and branch the build came from so the alert points at the right change. Repeated failures on the same site, or a build stuck far past its usual time, are handed to an engineer with the recent history attached, so a human judges whether it is a code issue or the platform.

Production rollbacks

Netlify keeps previous published deploys available to restore. When an agent detects a failed or reverted production release under the rule your team set, it gathers the current and prior deploy details and notifies the on-call engineer with both versions identified. It never rolls a site back on its own unless that action is explicitly pre-approved for a defined case. Any rollback decision that touches live traffic, or where the healthy deploy is unclear, is routed to a person who confirms which version should serve visitors.