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

# Schedule maintenance

> Turn flaky-test scans, feature-flag audits, and dependency reviews into recurring Roomote work.

## Overview

Every team has maintenance work that only happens when someone feels guilty:
flaky tests, stale feature flags, and aging dependencies. A custom automation
turns each chore into a standing appointment: a prompt, a cadence, and a channel
where results land in a replyable thread. Once you have built one, you will
start spotting more work that fits the pattern.

* **Trigger**: Schedule
* **Setup time**: About 15 minutes
* **Requires**: Admin access
* **Serves**: Engineers, Leads
* **Cooked By**: [Bruno Bergher](https://github.com/brunobergher) from [Roomote](https://roomote.dev)

## Ingredients

* One [custom automation](/automations#custom-automations) per chore, within the deployment cap of 25
* One environment per automation
* A report destination such as `#eng-maintenance`

## Steps

1. Under **Settings > Automations > Custom automations**, create an automation.
2. Pick a prompt below, choose a cadence, and select the environment. Natural-language schedules such as `weekdays at 9am` are supported under **Custom schedule**.
3. Set a report destination so results become a conversation rather than a log line.
4. Use **Run now** to check the first report, then let the schedule take over.
5. Reply in the thread to steer a run, for example `Open the PR for item 2`, without changing the automation.

## Prompt: flaky tests

Run weekly:

```text theme={null}
Find flaky tests. Look at recent CI runs for tests that failed and then passed
with no related code change. For each suspect, read the test and identify the
likely cause: timing, shared state, network, or ordering. Report the top 3 with
evidence. If one has an obvious, safe fix, open a PR for that one only.
```

## Prompt: stale feature flags

Run weekly or monthly:

```text theme={null}
Audit feature flags. List every flag defined in the codebase. Flag the ones
that are fully rolled out and effectively always on, referenced nowhere, or
whose code paths are dead. Report which can be removed and what removing them
simplifies. Open a cleanup PR for at most one clearly dead flag per run.
```

## Prompt: dependency review

Run weekly:

```text theme={null}
Review our dependencies for updates worth taking: security patches first,
then major versions of core frameworks. For each candidate, summarize what
changed upstream and the migration risk for our codebase specifically. Do not
open PRs. End with a ranked shortlist of updates worth scheduling this sprint.
```

## Variations

* Create a Monday briefing that summarizes open PRs, stale branches, and work waiting on review.
* Compare `apps/docs` with customer-visible changes shipped in the last week and report documentation drift.
* Use a model override for heavyweight audits and the deployment default for cheaper checks.

Custom automations also support five-field cron expressions, **Run now**, and
replyable result threads. Without a report destination, runs are silent and
their results appear only in the task view.

**Pairs well with:** [CI failure auto-fix](/cookbook/ci-failure-auto-fix) ·
[product-updates newsletter](/cookbook/product-updates-newsletter)