How engineering teams use Xurrent IMR's GitHub integration to close incidents before they become postmortems.
Here is how most engineering teams find out about a production incident: an alert fires in their monitoring tool, somebody creates a GitHub issue to track the work, someone else opens a separate war room, a third person updates the status page, and by the time the incident is resolved, there are four places that each have a partial version of what happened.
Nobody closed the loop. The GitHub issue is still open. The postmortem never got written. Three weeks later, the same alert fires.
The problem is not that your team is disorganized. It is that your tools are not talking to each other, so your team has to be the bridge. Xurrent IMR's GitHub integration removes that bridge requirement entirely.
What This Integration Does
An incident in IMR creates a GitHub issue automatically.
Resolve the incident in IMR — the issue closes in GitHub.
Close the issue in GitHub — the incident resolves in IMR.
Alert rules custom-route GitHub events to specific engineers, teams, or escalation policies.
Two-way sync
Why GitHub and incident management belong together
GitHub is where engineers already spend their day. Pull requests, code reviews, issue tracking — it all lives there. When something breaks in production, the instinct is to open a GitHub issue because that is the tool in front of you.
The problem is GitHub issues are not built for incident response. They do not page anyone. They do not know who is on-call. They do not escalate if nobody responds in five minutes. They do not measure MTTR or track whether the fix actually shipped.
Xurrent IMR is built for exactly those things. The integration does not force engineers out of GitHub — it connects GitHub to a system that can actually manage the incident, not just document it.
Use Cases
Use cases worth building around
Most integration guides walk you through setup steps. This is not that. These are the scenarios your team will actually face and how the integration handles each one.
Use Case 01
A deployment breaks prod. The issue tracker and the incident command should not be two separate conversations.
Without Xurrent IMR
Your team pushes a release. Within minutes, error rates spike. An engineer opens a GitHub issue to track the regression. Meanwhile, the on-call engineer in PagerDuty is working a separate incident with no visibility into the issue thread. Two parallel tracks, zero shared context.
With Xurrent IMR × GitHub
Enable the two-way integration. When IMR creates an incident, it automatically opens a corresponding GitHub issue with the incident context already populated. When your engineers update the GitHub issue — adding findings, tagging the commit that caused the regression — those updates flow back into IMR. One conversation, two surfaces. When IMR resolves the incident, GitHub closes the issue. When GitHub closes the issue, IMR resolves the incident. Nobody has to remember to do either.
The Payoff
The postmortem in IMR already has the full timeline. The GitHub issue has the fix commit linked. Nothing fell through the gap because there was no gap.
Use Case 02
A PR introduces a bug that does not surface until after merge. The on-call engineer needs context, fast.
Without Xurrent IMR
A pull request gets merged on Friday afternoon. Automated tests passed. By Friday evening, a customer reports something broken. The on-call engineer pages in, opens the incident, and has no idea where to start looking. The relevant PR and the issue thread are in GitHub. The incident is in PagerDuty. Context is scattered.
With Xurrent IMR × GitHub
IMR's GitHub integration supports Pull Request and Workflow Run events as alert sources. Configure a GitHub webhook to send PR events to IMR and set alert rules to route them based on repository, branch, or label. When a PR in a critical service merges, IMR can automatically create a tracking incident and attach it to the on-call policy for that service. The on-call engineer opens the incident and the linked PR is right there.
The Payoff
Response time drops because the engineer does not spend the first twenty minutes figuring out what changed. The context is pre-loaded. The fix is faster because the cause is visible.
Use Case 03
Your team runs Alert Rules to prevent the wrong person getting paged for a GitHub event.
Without Xurrent IMR
You have multiple repositories, multiple teams, and a shared PagerDuty account. A critical alert from the payments service should wake up the payments engineer, not the infrastructure engineer who happens to be on the general on-call rotation.
With Xurrent IMR × GitHub
IMR's Alert Rules let you write routing logic against any field in the GitHub webhook payload. Repository name, event type, issue label, branch name. A push to the payments repo routes to the payments escalation policy. A workflow failure on the main branch routes to the platform team. A critical issue label bypasses L1 and goes straight to L2. None of this requires a developer to configure it.
The Payoff
The right engineer gets paged for the right event. Nobody gets pulled into an incident that is not theirs. Alert fatigue drops because the signal is actually relevant to the person receiving it.
Use Case 04
Your workflow run fails at 3am. You want an incident, not just a notification.
Without Xurrent IMR
CI/CD pipelines fail. Usually it is a flaky test and nobody needs to wake up. Occasionally it is a deployment pipeline failure that means nothing is shipping until it is fixed. GitHub sends both events the same way. Your team currently ignores most of them because distinguishing signal from noise at 3am is hard.
With Xurrent IMR × GitHub
IMR supports Workflow Run as a webhook event type. Write an alert rule that creates a high-urgency incident only when the workflow run fails on the main branch in a production-deployment pipeline. Staging failures, feature branches, and test reruns go to a lower urgency queue or get suppressed entirely. The suppression rules live in IMR and can be updated by a service manager without touching the GitHub webhook configuration.
The Payoff
Your engineers sleep through the noise and get woken up for the signal. The distinction between 'flaky test' and 'prod deployment broken' is made by the system, not by a groggy engineer at 3am.
Use Case 05
The incident is resolved. The permanent fix still needs to ship. IMR and GitHub keep that tracked.
Without Xurrent IMR
Your team closes the incident. MTTR looks good. The immediate fix is in production. But the root cause is still there — a tech debt item that requires a proper fix, not a hotfix. That item goes into GitHub Issues with a plan to address it in the next sprint. Three sprints later, it has not shipped. The same incident fires again.
With Xurrent IMR × GitHub
When the IMR incident closes, the corresponding GitHub issue closes too. But before it closes, the responder adds a follow-up task inside IMR that links to a new GitHub issue for the permanent fix. That issue is tagged with a reliability-debt label and assigned to the relevant team. IMR tracks it as open reliability work. The postmortem references it. The sprint planning meeting has a paper trail.
The Payoff
The permanent fix gets visibility it would never have had if the loop closed at incident resolution. The same incident does not fire a third time because the root cause is tracked, assigned, and visible to engineering leadership.
Setting it up: what to know before you configure
The incoming integration (GitHub to IMR) and the outgoing integration (IMR to GitHub) are configured separately. Most teams need both. The incoming integration creates incidents from GitHub events. The outgoing integration creates GitHub issues from IMR incidents and keeps them in sync.
For the outgoing integration, you need a GitHub Personal Access Token with read and write access to Issues. Fine-grained tokens scoped to specific repositories are the better choice — they give you precise control over which repos IMR can write to, and they expire on a schedule you set. Classic tokens work but are broader than they need to be.
The cyclic loop warning in the docs is worth taking seriously. If you have both an incoming and outgoing integration pointing at the same repository, a GitHub event creates an IMR incident which creates a GitHub issue which creates another IMR incident. Scope your incoming integration to a separate repository from the one your outgoing integration writes to, or use alert rules to filter out events that IMR itself generates.
Quick Setup Checklist
1
Create a GitHub Personal Access Token (fine-grained, Issues read/write, scoped to target repos)
2
Configure Outgoing Integration in IMR under your service, paste the token, select the repository.
3
Test the connection to verify a test issue appears in GitHub.
4
Configure Incoming Integration in IMR, copy the Webhook URL.
5
Add the webhook to your GitHub repository, select the event types you want (Issues, Push, PR, Workflow Run)
6
Write Alert Rules to route events to the right teams and escalation policies.
7
Verify the two-way sync by resolving a test incident in IMR and confirming the GitHub issue closes.
GitHub issues are good at tracking work. They are not good at managing incidents. Xurrent IMR is good at managing incidents. The integration is not about replacing one with the other — it is about letting each do what it is built for while sharing context automatically.
The teams that get the most out of this integration are the ones who treat it as incident architecture, not just a tool connection. They write deliberate alert rules. They scope their tokens carefully. They map GitHub events to the escalation policies that match them. The setup takes a few hours. The payoff is an incident workflow where nothing falls through the gap because the gap no longer exists.
