Managing repositories

Enable or disable monitoring per repository, understand plan limits, pick the branch the AI analyzes, and know what the historical backfill covers.

Latchkey only ingests data for repositories you explicitly enable. You choose them during onboarding, and you can change them any time from the dashboard. Enabling is also what makes a repository eligible for managed runners: managed runners only serve monitored repositories.

The Monitoring modal#

In the dashboard sidebar, click Monitoring (visible to workspace owners and admins) to open Manage Repository Monitoring. The header shows how many repositories you are using against your plan limit. Each repository has a toggle; changes are queued as "pending changes" and applied together when you click Save Changes.

• Search and scroll: the list searches your organization live and loads more as you scroll.
• Branch selector: each monitored repository shows a branch picker that sets the branch Latchkey's AI analyzes for workflow optimizations (defaults to the repository default branch). Workflows that exist only on other branches are not analyzed.
• Permissions: enabling and disabling monitoring requires an owner or admin role.

Plan limits#

At your limit, additional toggles are blocked and the modal points you to upgrade. On Developer, the single monitored repository cannot be swapped from the modal; upgrading to Launch or Scale unlocks that.

Choosing repositories under a limit#

When you have more repositories than slots, treat the limit as a prioritization question:

• Anything you want on managed runners must be monitored. Jobs targeting latchkey-* labels from an unmonitored repository never get picked up; they stay queued on GitHub. If runner adoption is the goal, those repositories come first.
• High-activity repositories give the analytics the most to work with. The dashboards and the AI's recommendations are built from your workflow runs, so a repository that runs CI many times a day produces far more signal than one that builds weekly.
• A chronically failing pipeline is a strong candidate. Repeated consecutive failures trigger diagnostic analyses, so the flaky repository is often where the AI earns its keep first. See Optimization insights.
• On Developer, choose deliberately. The single monitored repository cannot be swapped from the modal, so pick the repository whose CI you most want to understand; upgrading to Launch or Scale unlocks swapping.

What happens when you enable a repository#

Progress banners show in the dashboard while backfill and the first AI analysis run, so you always know what is still warming up.

What backfill does and does not cover#

Backfill exists to make the dashboard useful on day one instead of after a week of collecting. It imports recent completed runs from the past 30 days, which is enough to seed the cost, performance, and insights pages with real numbers; most teams see data within a few minutes. Two expectations worth setting: it is a sample, not a full history import, and it can only import what exists. A repository with no workflow runs in the last 30 days backfills nothing, and its pages stay empty until new runs happen. The dashboard's date-range filter also has to overlap the activity, so if a page looks empty right after backfill, widen the range before assuming something is wrong.

What happens when you disable a repository#

Disabling stops ingestion for that repository immediately and frees the slot against your plan limit. Its historical data is archived rather than shown in the dashboard. Because managed runners only serve monitored repositories, jobs in that repository targeting latchkey-* labels will queue rather than run until it is re-enabled. Re-enabling later starts a fresh backfill.

Common questions#