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

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
• belong to the right user
• even be synced already

and still not be eligible for Triggers or Automations if the GitHub App is not installed for the owner that controls that repo.

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

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

User-level GitHub state

The account connection can show up in states like:

These are account signals, not repo signals.

Repo-level coverage state

Each repo effectively falls into one of these buckets:

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

What the installations surface exposes

The installations data shown in 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

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

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

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

1. Check Settings and read the current GitHub status label
2. Confirm the expected owner or org appears in Installations
3. Check whether the repo is actually Trigger-ready, not just visible in Projects
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