# Coverage and Triggerability (/web/installations/coverage-and-triggerability)



Most setup confusion in Mogplex comes from mixing up three different states:

* GitHub account connected
* repo visible in Mogplex
* repo triggerable for webhook-backed work

Those are related, but they are not the same thing.

## OAuth is not enough [#oauth-is-not-enough]

GitHub OAuth can be enough to connect an account and discover repositories.

But webhook-backed routing depends on GitHub App coverage.

That means a repo can still:

* appear in [Projects](/web/spaces)
* belong to the right user
* even be synced already

and still not be eligible for [Triggers](/web/triggers) or
[Automations](/web/automations) if the GitHub App is not installed for the
owner that controls that repo.

## What "triggerable" actually means [#what-triggerable-actually-means]

Operationally, a repo becomes triggerable when Mogplex can associate it with a
real GitHub App installation id.

That installation id is the bridge between:

* GitHub webhook events
* synced repos in Mogplex
* installation-scoped routing surfaces

Without that bridge, Mogplex can see the repo but cannot safely route
App-backed automation into it.

## Two different state layers [#two-different-state-layers]

Mogplex exposes both a user-level GitHub state and a repo-level coverage state.

### User-level GitHub state [#user-level-github-state]

The account connection can show up in states like:

| State             | Meaning                                                            |
| ----------------- | ------------------------------------------------------------------ |
| `OAuth only`      | GitHub is connected, but routing still needs App coverage          |
| `Install pending` | The App install was started, but GitHub still needs to finish it   |
| `App installed`   | Coverage exists, but no covered repos are synced into Projects yet |
| `Ready`           | App coverage is active and covered repos are already synced        |

These are account signals, not repo signals.

### Repo-level coverage state [#repo-level-coverage-state]

Each repo effectively falls into one of these buckets:

| Repo label      | Meaning                                                                             |
| --------------- | ----------------------------------------------------------------------------------- |
| `Trigger-ready` | The repo has a `github_installation_id` and can participate in App-backed routing   |
| `Synced only`   | The repo is visible in Projects, but has no App coverage yet                        |
| `Not covered`   | The App is installed somewhere for the user, but not for this repo's owner or scope |

This is the state that matters when the question is "will this route wake up?"

## What the installations surface exposes [#what-the-installations-surface-exposes]

The installations data shown in [Settings](/web/settings) exists to answer a
very practical question:

"Which GitHub owner scopes are actually available for App-backed automation?"

Each installation surfaces:

* account or org login
* scope label such as `Org`, `User`, or `Account`
* synced repo count for the installation
* a GitHub manage link when the metadata is complete enough to build one
* the repos Mogplex currently associates with that installation

If installation metadata is incomplete, Mogplex will try to refresh it from
GitHub before presenting the final view.

## Reconciliation can fill in missing installation state [#reconciliation-can-fill-in-missing-installation-state]

Mogplex does not only rely on the user manually refreshing setup pages.

If the app has GitHub App config and knows your GitHub username, the hosted
surfaces can attempt to reconcile installation state when the current install
list is still empty.

That is why these pages can sometimes "heal" after an install finishes in
GitHub even if you did not manually resync every step yourself.

## Typical failure symptoms [#typical-failure-symptoms]

When coverage is missing or wrong, users usually see one of these:

* Triggers is empty
* Automations cannot find the installation they expect
* a repo shows up in Projects but cannot participate in webhook routing
* Settings says GitHub is connected, but the status is still `OAuth only`
* Settings shows an App installation, but the repo you care about is still
  `Synced only` or `Not covered`

## Mental model [#mental-model]

Use this rule:

* OAuth answers "who are you?"
* installation coverage answers "which owners and repos can Mogplex automate?"

If the question is about routing, coverage is the thing that matters.

## Good troubleshooting order [#good-troubleshooting-order]

1. Check [Settings](/web/settings) and read the current GitHub status label
2. Confirm the expected owner or org appears in [Installations](/web/installations)
3. Check whether the repo is actually `Trigger-ready`, not just visible in
   [Projects](/web/spaces)
4. If the App install recently changed, let Mogplex reconcile or rerun repo
   sync
5. Retry the exact GitHub event you expect, then confirm it in
   [Observability](/web/observability)