Code repositories

Access to the codebase is often the difference between a quick resolution and hours of guesswork. Connecting your repositories gives investigations the same advantage: they can identify recently merged pull requests that may have caused an issue, trace error paths through the code, and understand how services fit together. With write access, responders can also ask an investigation to draft a fix and open a pull request.

​

How investigations use this

Investigations work with your code in two complementary ways: they keep a continually-updated picture of every change you ship, and — when a hypothesis calls for it — they read the code itself.

​

Finding the change that caused it

incident.io tracks every pull request and merge request as it moves through your workflow. When one merges, we process it in the background and enrich it with an AI summary of what it does, category tags, the files it touched, and its commits and full diff — building a searchable index of your changes rather than a flat list of titles. During an investigation, that index is searched for the changes most likely to be responsible — the recent merges, plus any whose summaries line up with the alert and the symptoms — and each one is weighed for whether it could actually have caused what you’re seeing. A change whose summary matches the failure is exactly what gets surfaced, with a link to the diff. This is where change events come in. A merged pull request tells you a change exists; a deploy change event tells you it actually shipped, and when. By tying deploys back to the specific commits they carried, an investigation can rule a change in or out on timing — a pull request that merged last week but only reached production two minutes before the first error is far more interesting than one that’s been live for days.

​

Reading the code

Linking changes only goes so far. When a hypothesis needs confirming in the code itself, the investigation clones the relevant repositories and runs a full coding agent against them. Across organizations with thousands of repositories, the investigation narrows to the handful worth cloning by matching the incident against repository names, recent merge activity, and an AI-built understanding of what each repository is for and how it’s structured. Once a repository is cloned, the agent does what an engineer would: it plans the specific questions worth answering, then reads the code to answer them — tracing a call path across files, following an error back to where it’s thrown, checking what a recent commit actually changed. It’s the difference between guessing from an error message and reading the line that produced it. See How investigations work. With write access, that same capability can go a step further and draft a fix as a pull request for you to review.

​

Security

Code access is built to touch as little as possible, for as short a time as possible. We clone repositories only when we need them. An investigation doesn’t mirror or hold a copy of your codebase. It clones a repository only at the moment it needs to read code to test a hypothesis, and only the specific repositories relevant to the incident — never your whole estate. Each clone lands in its own ephemeral workspace that’s deleted as soon as the analysis finishes. The code agent runs in a locked-down sandbox. Analysis happens inside an isolated container that exists only for that work. It has no inbound network access and tightly restricted outbound access, and it can see only the code we’ve cloned and the investigation’s own context — nothing else on your systems or ours. We only use the access you grant. Everything stays within the permissions you’ve configured. If you’ve connected read-only, an investigation can read and analyze your code but can never write to your repositories — see the access levels below for exactly what each permission allows. This whole setup — cloning, isolation, and execution — has been audited by external penetration testers. For more on how we handle your data during AI processing, see our Trust Center.

​

Setup

Connect your code provider from the integrations settings in your dashboard. We only ever use the access you grant for the work described above — reading the changes and code behind an incident, and, if you allow it, drafting a fix. Both providers support two access levels:

• Read only — investigations can read your code, clone repositories to analyze them, and link the pull requests behind an incident.
• Read and write (recommended) — adds a single capability on top: opening a pull request with a drafted fix for you to review.

​

GitHub

incident.io connects to GitHub as a GitHub App installed into your organization, authenticating with short-lived installation tokens rather than anyone’s personal account. Access is scoped to the app and isn’t tied to an individual, so it survives people joining or leaving the team. Both GitHub.com and GitHub Enterprise Server (self-hosted) are supported — on Enterprise Server you install a dedicated app against your own instance. The access level you choose maps to these permissions: We request nothing beyond these, and the read-only configuration carries no write permission of any kind.

​

GitLab

incident.io connects to GitLab with a personal access token created for a dedicated service account user, so the integration isn’t tied to a real person’s account. Both GitLab.com and self-managed instances are supported. Two things decide what investigations can do: the service account’s project role and the token’s scopes. A few details worth knowing:

• The same token is used both to read merge request data and to clone repositories, so its scopes need to cover both.
• api is a superset of read_api + read_repository, so a single api-scoped token works for either access level — but for a read-only setup, the narrower pair keeps the grant as small as possible.
• Self-managed GitLab: if your instance restricts access by IP address, allow incident.io’s IP ranges so we can reach it.

For step-by-step setup, see the GitLab integration guide.

​

Private and self-hosted instances

If your GitHub Enterprise Server or self-managed GitLab instance runs inside a private network and isn’t reachable from the public internet, connect it through a Connector — a lightweight proxy you run inside your own network that opens a secure, outbound-only tunnel to incident.io. We reach your instance over that tunnel, so there’s no need to open inbound firewall ports or expose it publicly.

​

Related