> ## 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.

# Evaluate outage impact

> Filter vendor status noise by comparing each incident with your real code, regions, and feature usage.

## Overview

Every vendor you depend on publishes status updates, and almost none of them
affect you, until one does. Pipe them into one channel and let Roomote read each
incident against your actual code: which SDKs you call, which regions you run
in, and which features you use. You stop triaging vendor noise by hand and only
hear about the outages that matter. This is how we run it at Roo.

* **Trigger**: Channel event
* **Setup time**: About 20 minutes
* **Requires**: Admin access, Slack or Discord
* **Serves**: On-call, Support
* **Cooked By**: [Matt Rubens](https://github.com/mrubens)

## Ingredients

* A Slack or Discord channel such as `#vendor-status` receiving vendor status
  feeds. Most vendors offer Subscribe via Slack, RSS-to-channel, or
  email-to-channel.
* [Auto-respond channels](/automations#channel-automations)
* An [environment](/environments) covering the repositories that use these
  vendors
* Roomote invited to the channel on Slack, or able to see it on Discord

## Steps

1. Create `#vendor-status` and subscribe it to every upstream status page you care about.
2. Invite Roomote to the channel.
3. Under **Settings > Automations > Auto-respond to channels**, add the channel.
4. Paste the launch criteria and instructions below.
5. Post a fake incident and confirm a task launches. Then post a scheduled-maintenance notice and confirm it does not.

## Launch criteria

Paste this into the channel's **Launch criteria** field:

```text theme={null}
Launch only for messages reporting a new incident, a worsening incident, or an
incident that regressed after being resolved, from one of our upstream vendors.

Do not launch for scheduled-maintenance announcements, "monitoring" or
"resolved" updates to an incident already investigated, changelog or marketing
posts, or duplicate notifications about the same incident.

Treat a message as an escalation when it adds affected components, expands
impact, or reports a worse status than before. When unsure whether an incident
could plausibly touch something we depend on in production, launch: a wasted
check is cheaper than a missed outage.
```

## Instructions

Paste this into the channel's **Instructions** field. Roomote gives these
instructions to every task launched from the channel.

```text theme={null}
A vendor has posted a status incident. Determine whether it affects us:

1. Identify the vendor and the affected components, regions, and features
   from the message.
2. Search the codebase for how we actually use this vendor: SDKs, API
   endpoints, features, and regions we depend on.
3. Compare our real usage against what the incident says is affected.
4. Reply in the thread with a clear verdict:
   - "Affects us": which features or code paths, likely user impact, and a
     suggested action.
   - "Safe to ignore": why our usage is not touched.

Keep it short. The on-call engineer reads this thread. Do not page anyone.
```

## Variations

* Name the vendors explicitly in the criteria to ignore feeds subscribed to just in case.
* Ask Roomote to describe how to verify recovery whenever the verdict is **Affects us**.
* Use a multi-repository environment so the usage search covers every service.

Auto-respond channels support Slack and Discord today. On Teams or Telegram,
forward status events to a supported channel or mention Roomote from a workflow.

**Pairs well with:** [CI failure auto-fix](/cookbook/ci-failure-auto-fix) ·
[support channel](/cookbook/support-channel)