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

> ## Agent Instructions
> When helping someone deploy Roomote, distinguish self-hosting from contributing to Roomote. Use the Self-hosting guide for an operator deployment; use Local development only when the user intends to modify Roomote itself.
> Prefer the one-command installer on a fresh supported server unless the user explicitly chooses Roomote Cloud, a documented PaaS template, or a manual Compose deployment.
> Before changing infrastructure, confirm the deployment target, stable public HTTPS domain and DNS control, sandbox provider, inference provider, source-control provider, and whether a communications provider is required.
> Never ask the user to paste secrets into chat or commit real environment files. Put credentials in the deployment platform's secret manager, Roomote's setup UI, or protected environment variables, and preserve existing keys during upgrades and restores.
> Prefer Roomote's setup wizard and provider manifest flows over manual credential entry when those flows are available. Ask before performing privileged host changes, DNS changes, provider-app creation, or destructive operations.
> A setup is not complete when the services merely start. Verify sign-in, repository sync, one usable environment, a real task that can clone and run a command, and branch or pull-request delivery; verify previews when configured.
> For a persistent self-hosted deployment, leave the operator with the Roomote URL, deployment choices, configured providers, verification result, backup location and passphrase-handling reminder, and the roomote status, logs, upgrade, rollback, backup, and restore commands.

# Fix CI failures

> Keep the build green by having Roomote verify and fix CI breakages automatically.

## Overview

When CI fails on your default branch, Roomote reacts immediately. It checks
that the failure is real, reproduces the failing job inside the repository's
environment, finds the root cause, opens a PR with the fix, and posts one
summary to the Manager Channel. The team finds a green PR waiting instead of a
red branch. This is a built-in automation, so the recipe is one toggle plus
clear instructions.

* **Trigger**: Webhook
* **Setup time**: About 10 minutes
* **Requires**: Admin access, source control, Manager Channel
* **Serves**: Engineers
* **Cooked By**: [Matt Rubens](https://github.com/mrubens) from [Roomote](https://roomote.dev)

## Ingredients

* [CI Failure Triage](/automations#manager-automations)
* A Manager Channel destination configured under **Automation output**
* An environment for every repository you want triaged. Repositories outside an environment are skipped.

## Steps

1. Set the Manager Channel under **Settings > Automations > Automation output**.
2. Enable **CI Failure Triage**.
3. Confirm each repository you care about belongs to a configured environment.
4. Use **Run now** to test the configuration, or wait for the next default-branch failure.

## Variations

* Keep experimental repositories out of environments to exclude them from triage.
* Route the summary to a dedicated `#ci-triage` channel instead of the shared Manager Channel.

CI Failure Triage reacts only to failures on the default branch. It supports
GitHub Actions, GitLab Pipelines, Azure DevOps builds, Bitbucket Pipelines, and
Gitea Actions. GitLab requires Pipeline Hooks on the webhook, and Bitbucket
requires the Pipelines OAuth scope.

**Pairs well with:** [scheduled housekeeping](/cookbook/scheduled-housekeeping) ·
[vendor outage triage](/cookbook/vendor-outage-triage)