Skip to main content
The GitHub integration gives sureops read access to your repositories for service ownership context and deployment correlation. It also underpins two separate write paths that each have their own configuration, not the Default Repository field below: fix PRs (when a diagnosis points to a code change as the root cause, the resolution specialist can open a draft PR reverting or patching it) and postmortem PRs (RCA documents opened as a PR against your knowledge base repo). See What this integration enables for how each one is routed.

​
What this integration enables

  • Repository context — the contract ingestor reads .sureops/services.yaml and .sureops/runbooks/ from your knowledge-base repo to understand service ownership and relevant runbooks. catalog-info.yaml can also be imported through the Backstage import flow — paste its URL or upload the YAML directly — rather than being auto-discovered from arbitrary service repos
  • Fix PRs — for an approved code-change recommendation, the resolution specialist opens a draft PR against the specific service’s repo. That repo is resolved from the service’s built_from mapping in .sureops/services.yaml — not the Default Repository field below. If a service has no built_from mapping, the fix PR can’t be opened for it.
  • Postmortem PRs — sureops can open a PR with the RCA/postmortem document against your knowledge base repo. That repo comes from your org’s Knowledge Base configuration (Settings → Knowledge Base) — also not the Default Repository field below. If no Knowledge Base repo is configured, the postmortem PR is silently skipped (logged, no error surfaced).
  • Deployment correlation — agents can correlate recent commits and PR merges with incident timing during diagnosis
  • Change-tracking issues — sureops files GitHub Issues as change-tracking records for incidents (when GitHub is selected as your change tracker). This is the one write path that actually reads the Default Repository field below.

​
Prerequisites

  • An environment selected in the top-right context switcher — Settings → Environment → Integrations is scoped to that environment and stays disabled until one is selected
  • A GitHub organization where you have Owner or sufficient admin permissions
  • An MCP endpoint sureops can reach for GitHub, plus a credential to authenticate to it (see the Warning in Setup below for the current state of the intended GitHub App install path)
Integration connections are per-environment. Connecting GitHub here only applies to the environment that was selected in the context switcher at the time — it does not carry over to your other environments. Repeat this connect flow for each environment that needs GitHub.

​
Setup

The architecture intent (see How integrations work) is that GitHub connects via a GitHub App install — sureops runs a shared MCP pod and authenticates each call with your App installation token, so there’s nothing for you to stand up. That install redirect is not reachable from the connect screen today: GitHub has no vendor-hosted MCP endpoint wired into the connect flow, so it’s pinned to the same generic MCP-endpoint form used by Grafana, Prometheus, and the other customer-hosted integrations. What’s below is the connect form as it works today: an MCP-endpoint + credential set, not a GitHub App install redirect.
1

Connect in sureops

In sureops, go to Settings → Environment → Integrations and click Connect next to GitHub.Fill in:
  • MCP Server Endpoint — the URL of the MCP server sureops should use to reach GitHub
  • Authentication Method — Bearer Token, API Key, or Basic Auth
  • Token — labeled Bearer Token, API Key, or Password depending on the method you selected above
Click Save & Connect.
2

Configure a default repository (optional, after connecting)

Once connected, reopen the GitHub integration from Settings → Environment → Integrations. A Settings section appears below the connection status with a Default Repository field — set it there, not on the connect form.Format: owner/repo (for example, acme/incidents). This field is used only by the change-tracking issue feature — it does not affect fix PRs or postmortem PRs (see What this integration enables). If left blank, GitHub still works for read-only context, but the moment an agent tries to file a change-tracking issue, that action fails loudly with a “missing repo” error rather than failing silently. Set this field if you want change-tracking issues to work.Fix PRs and postmortem PRs have their own separate prerequisites: a fix PR needs the target service mapped via .sureops/services.yaml’s built_from field, and a postmortem PR needs a Knowledge Base repo configured under Settings → Knowledge Base. Neither reads this field.

​
Configuration fields

Fields collected when you connect the integration: Field configured afterward, via the integration’s Settings section once connected:

​
Common errors

​
Official documentation