GitHub integration

The GitHub integration connects Errorgap triage to the place where many teams track code changes and fixes. Use it to create issues from error groups, link existing work, and keep deploy context close to production failures.

What GitHub is for

GitHub is useful when an error group needs code work or longer-lived tracking. Errorgap keeps the runtime context, stack trace, and occurrences; GitHub keeps the implementation discussion, pull request, and fix history.

• Create a GitHub issue from an actionable error group.
• Link an existing issue when work is already underway.
• Use release or deploy context to understand what changed near a failure.
• Keep the Errorgap group linked to the issue teammates use for the fix.

Before you connect

Decide which repository should receive issues for the project. The best repository is the one where the owning team expects to review fixes for the application or service.

• Confirm the project maps to the right application or service repository.
• Choose the repository where fixes and issue triage should happen.
• Agree on labels or issue conventions your team wants to use for production errors.
• Make sure teammates know Errorgap remains the source for runtime context.

Connect a project

1. Open the project you want to connect.
2. Go to project settings and open integrations.
3. Select GitHub.
4. Choose the repository that owns the project code.
5. Save the integration settings.
6. Create or link a test issue from a safe error group to confirm the workflow.

If your organization has already authorized GitHub, connecting a project should only require choosing the repository and project-level behavior available to you.

Create issues from errors

Create a GitHub issue when an error group needs investigation, a code change, or planned follow-up. The issue should include enough context for someone to start without repeating triage.

• Open the error group that needs work.
• Review the message, stack trace, environment, release, and latest occurrence.
• Create a GitHub issue from the group or link an existing issue.
• Add labels, assignees, or project metadata using your team conventions.
• Keep the Errorgap group linked so future occurrences point back to the same work.

Use release context

Release context helps connect a production failure to recent code changes. When an error appears after a deploy, compare the first seen time and release value with recent commits, pull requests, and issue activity.

• Check whether the error first appeared after a specific release.
• Review recent pull requests that touched the application frame.
• Use source paths and stack frames to identify likely owners.
• Watch the Errorgap group after the fix merges and ships.

Close the loop

Keep Errorgap and GitHub aligned as the work progresses. The issue can track implementation, but the Errorgap group should reflect the current runtime state.

• Assign the Errorgap group or incident when someone owns the next step.
• Update the GitHub issue with important runtime findings from Errorgap.
• Resolve the Errorgap group after the fix ships and occurrences stop.
• Reopen or treat the group as regressed if it returns after resolution.

Troubleshooting

If issue creation or links do not behave as expected, start with the project integration and repository selection.

• Confirm GitHub is enabled for the project you are viewing.
• Check that the selected repository is the expected destination.
• Confirm you have access to create or view issues in that repository.
• Check whether the error group is already linked to an existing issue.
• Try linking a known issue before creating a new one if duplicates are a concern.