This site is being rebuilt and some pages are out of date. For current details, write to reach@inorbit.hr. This notice goes away when the rebuild is done.

No analytics unless you allow it, no tracking. This site keeps in your browser the language you pick, the theme, its colour, which site you chose, the currency on the pricing page and that you closed this notice; signing in adds session cookies. The legal page has the details.

Sign in

← Back to Platform

RFC 0077open2026-10-06

The GitHub agent, fixes that find their incidents

A pull request that names an incident is recorded on it when it merges, goes live and holds.

Problem

An incident ends with a fix in a repository, and the postmortem then has to say which change it was, when it shipped and whether it worked. Today someone copies the pull request's number into the postmortem's repair section by hand, and nobody writes down when it went live or what the monitors measured afterwards. The incident of 2026-10-05 (the API gateway copying itself for every connection) is an example: the repair was pull request #326, and the postmortem names it only because a person typed it.

The platform already holds both ends. Incidents and postmortems live in it (RFC 0058), with timelines and evidence. The InOrbit GitHub App (RFC 0044, phase 3) is installed on an account's repositories and RFC 0041 already reads its pull_request events to show which pull requests implement an RFC. What is missing is the link from a merged change to the incident it fixed, and the measurement that says the fix held.

Proposal

One line in the pull request

A pull request names the incident it fixes in its description, one line per incident, in the same form RFC 0041 uses for RFCs:

Fixes: INC-6P4Q8W
Mitigates: INC-6P4Q8W
Closes: INC-6P4Q8W action 2

INC- and the last six characters of the incident's id are what the app and the console already show and what a person reads aloud. Fixes marks the repair, Mitigates a stopgap (a raised limit, a rollback), Closes ... action N one of the postmortem's action items. Only these lines link a pull request to an incident; a mention in the title or a comment does not, so a link is always something a person wrote on purpose.

What the agent records

The agent acts on the App's pull_request events for repositories the account installed it on, and records each step on the incident, with the pull request as typed evidence (pr:<owner>/<repo>#<number>):

  1. Opened or edited with a link. The incident's timeline gets "Fix proposed: #326, One router for every connection". The pull request gets one comment from the App with a link to the incident.
  2. Merged. The timeline gets "Fix merged" with the merge commit. A Fixes pull request is added to the postmortem's evidence and listed under its repair section; a Closes ... action N pull request marks that action item done and links it.
  3. Live. When a roll records the merge commit as running (RFC 0041's "live", from the platform's rolls or the account's own deploy events), the timeline gets "Fix live".
  4. Proved. From the moment it went live, the agent compares the incident's monitors over a window of the same length before and after (failed runs, availability, p95). When the after window holds, the timeline gets "Fix held: error rate 15.0 % before, 0 % in the 30 minutes after", and the agent updates its comment on the pull request with the same numbers. When it does not hold, it says that instead, and the incident shows it at the top.

A pull request closed without merging is recorded as abandoned, and its proposal stays in the timeline. Nothing is removed: the timeline is history.

A diagram is drawn here in the RFCs product; this page does not show diagrams yet.

Suggestions, confirmed by a person

People forget the line. When a pull request merges in a repository linked to an open or recently resolved incident's monitors, and it has no link, the agent may suggest one: on the incident ("Was #331 the fix?") and as a comment on the pull request with the line to add. The suggestion comes from simple facts (the repository the incident's monitors belong to, the time, the files near the failing service), says that it is a suggestion from an agent, and records nothing until a person with edit rights on the incident confirms it in the app or the console, or adds the line. A wrong link in a postmortem is worse than a missing one.

Installing it

A customer sets the agent up from the console, without us:

  1. Connections, GitHub, Install the InOrbit Agent sends the person to GitHub's install page for the App, with a state the console signed for that person and account.
  2. The person picks the organization and the repositories and installs. GitHub sends them back to the App's Setup URL, the console's /connections/github/ page, with installation_id and setup_action.
  3. GitHub warns that anyone can call a Setup URL with an installation_id that is not theirs (GitHub). So the page trusts neither the parameter nor the App's own view of the installation. It checks the state, then asks the person to authorize the App once on GitHub (the App's user authorization, with the same page as its callback URL), and links the installation only if GitHub lists it among the person's own installations (GET /user/installations). The user token is used for that one check and discarded.
  4. The installation becomes the account's github connection: the page shows its repositories and the switch "Report fixes to incidents", off until the person turns it on.

A diagram is drawn here in the RFCs product; this page does not show diagrams yet.

"Redirect on update" brings the person back to the same page when they add or remove repositories, and the page shows the new list. GitHub sends every App the installation and installation_repositories events without a subscription (GitHub); the agent unlinks a connection when its installation is deleted, pauses it while suspended, and follows repository changes, so the console never shows access the App no longer has.

The App stays private to our own organization until reporting works end to end (slice 2). Then it is switched to installable by any account, which GitHub does not allow to be undone once another account has installed it.

Where it shows

  • The console: Connections, GitHub, a switch "Report fixes to incidents" per installation, and the repositories it covers. The incident page shows the linked pull requests with their state (proposed, merged, live, held).
  • The app: the incident's timeline and evidence show the same entries; the incident list shows "fix live" or "fix held" on a resolved incident.
  • The site: the integrations page lists the GitHub agent with what it does and what it reads, and the docs describe the Fixes: line.

What the App may read and write

The App asks for the least GitHub allows for this: read access to pull requests and metadata, and write access to pull request comments for its own comment. It does not read code. The platform keeps, per pull request, the repository, number, title, author's login, state, the merge commit and the times; never a diff, a file or a body beyond the link lines. Webhook deliveries are verified with GitHub's signature before anything is read, and an installation maps to exactly one account.

Security and compliance

  • Access control. An event is accepted only with a valid signature from GitHub, and only for an installation the account connected. A link can only reach incidents of the account the installation belongs to; a pull request that names another account's incident records nothing and says so in its comment.
  • No code leaves GitHub. The agent needs metadata only, and the App's permissions enforce it.
  • AI disclosure. A suggestion is labelled as coming from an agent (AI Act Art. 50 when a model writes it); the first version uses rules, not a model.
  • Audit. Every recorded step is logged with the installation, the pull request and the incident, never content.
  • Personal data. An author's GitHub login is personal data; it is kept with the incident for as long as the incident is, and covered by erasure.

Plan

  1. This RFC.
  2. The link lines, the pull_request events for incidents, timeline and evidence entries, the App's comment; installing from the console (the Setup URL page, its checks, the installation events) and the switch.
  3. Live and proved: rolls and deploy events, the before and after comparison, the comment updated with the numbers; the app and the console show the state.
  4. Suggestions with confirmation in the app and the console.
  5. The site's integrations page and the docs page.
  6. Reading the code and proposing fixes: RFC 0077.1.
  7. One state machine from proposal to resolved, with merges and rolls under a person's approval: RFC 0101.

Alternatives considered

  • Link any pull request merged during an incident. Automatic and usually wrong: a busy repository merges unrelated changes during every incident. Rejected; the line or a person's confirmation is the link.
  • Read commits and diffs to decide. Better suggestions, but the App would need code access, and code would pass through the platform. Rejected for now; suggestions use metadata.
  • Use GitHub's own issue links (Fixes #123). Those close GitHub issues; incidents live in the platform, and an incident is not an issue in a customer's repository.

Decision

Open. The owner asked on 2026-10-06 for an InOrbit GitHub agent that reports merged fixes to incidents and postmortems, in the console, the app and on the site.

Publication

Public.

Status log

  • 2026-10-06: Opened at the owner's request.
  • 2026-10-06: The App exists as InOrbit Agent, installed on our own organization; the long-run part (reading code, proposing fixes) is RFC 0077.1.
  • 2026-10-06: Installing it from the console: the Setup URL page, the user-authorization check GitHub asks for, and the installation events.
  • 2026-10-07: Checked: the App is installed; nothing else is built. Open.
  • 2026-10-09: The states a fix moves through, from proposed to resolved, are RFC 0101.

Parts

This document mentions

Mentioned in

← Back to Platform