Skip to main content
When sureops helps you resolve a problem, it can push the problem record to GitHub Issues automatically. This keeps your team’s external workflow in sync with sureops’s analysis — title, description, and resolution all flow outward without manual copy-paste. GitHub is fully self-serve — connect it directly from Settings → Integrations. Linear is also a fully supported tracker provider (sync works end-to-end), but there’s no self-serve connect flow for it yet: your sureops onboarding contact provisions it for you, the same way they handle target-repository and label configuration for GitHub (see “Who can configure this” below). Jira integration is coming soon; it isn’t connectable yet.
Tracker sync is a one-way push. sureops is the source of truth; updates made directly in your issue tracker are not reflected back in sureops.

​
What gets synced

When tracker sync is enabled, sureops keeps the following in step with your GitHub repository: Automatic sync fires only on these two events. Moving a problem through Investigating → Root Cause Identified → In progress doesn’t touch the GitHub issue — those intermediate transitions are visible in sureops only, until the problem is marked resolved.

​
Who can configure this

Tracker sync configuration currently has no Settings UI — it’s set up through your sureops onboarding contact, who configures the GitHub repository, labels, and state mappings on your behalf as part of connecting the integration.
  • Push problems to the tracker: any role with problems:write capability (Responder and above) can promote an incident to a problem, which pushes it to the tracker immediately — there’s no “wait for manual promotion” mode for problem records; every problem creation pushes unconditionally
See Roles & Capabilities for details.

​
Setup

1

Connect GitHub

Your Admin enables the GitHub integration from Settings → Integrations. This requires MCP access — your Admin will complete the GitHub App installation during this step.
2

Configure your target repository

Since there’s no self-serve config screen for tracker sync yet, tell your sureops onboarding contact which repository should receive problem issues, in owner/repo format — for example, acme/incident-tracking. They’ll also help you set:
  • Labels — any labels you configure are applied to every issue sureops creates, merged with the default sureops-problem label — that default label is always added, not just a fallback for when you haven’t configured your own
  • Resolved label — the single label applied when a problem is marked resolved. Closing a problem always sets the issue’s state to closed and replaces its entire label set with just this label — it isn’t a choice between state or label, both happen together, and any other labels (including the default sureops-problem label) are removed rather than kept alongside it
You can change the target repository later, but existing problem records stay linked to their original issue — they won’t be migrated automatically.

​
Using tracker sync

​
Creating a problem from an incident

1

Open the incident detail page

Navigate to the incident you want to convert into a tracked problem.
2

Promote to Problem

Click Promote to Problem. Fill in the Title, optionally set a Severity (recorded for audit only — problems are actually categorized by clustering, not severity), and optionally add a Reason, then click Promote. There’s no description field on this form.
3

Automatic push

The issue appears in your GitHub repository within seconds — every problem push happens automatically, immediately on creation; there’s no toggle to defer it. The problem record stores the external issue ID so all future updates go to the same issue.

​
What the GitHub issue looks like

Each issue sureops creates includes:
  • The problem description
  • A Root cause section, once one is known
  • A Recurrence note linking back to the full chain in sureops, if this problem is a recurrence of an earlier one
  • A Metadata block with category, status, customers affected, revenue impact, and downtime (whichever fields are populated)
  • A deep link back to the problem’s detail page in sureops

​
Resolving a problem

When you mark a problem resolved in sureops, the linked GitHub issue closes automatically: its state is set to closed and its label set is replaced with just the configured resolved label. No manual action needed in your tracker.
Closing always replaces the issue’s entire label set rather than adding to it — this is how sureops applies labels on close. Any other labels on the issue, including the default sureops-problem label, are removed at that point rather than preserved alongside the resolved label.

​
Retrying a failed push

There’s no customer-facing “push” or “retry” button today — pushes happen automatically on problem creation and when a problem is marked resolved. If a push fails, sureops does not retry it automatically — there’s no scheduled retry job. Contact your sureops support contact to have a failed push retried.

​
Troubleshooting

The integration exists but is in an error state — authentication may have lapsed or the integration service is temporarily unreachable.Fix:
  1. Ask your Admin to check Settings → Integrations for GitHub
  2. If the health indicator is red, disconnect and reconnect the integration to re-authenticate
  3. Contact your sureops support contact if the push needs to be retried
If the problem persists, contact your sureops support contact.
The target repository configured for tracker sync doesn’t exist or isn’t accessible to sureops.Fix:
  1. Verify the repository name is exactly correct, in owner/repo format (check for typos, extra slashes, or URL vs. path format issues)
  2. Confirm the GitHub App installation has access to the target repository — check Settings → Integrations → GitHub’s app permissions
  3. Contact your sureops onboarding contact to update the configured repository
The issue was created in GitHub but sureops couldn’t store the external issue ID. This is a transient error.Fix: This doesn’t retry automatically — there’s no scheduled retry job for failed pushes. Contact your Admin or your sureops support contact to have it retried.
A failed push stays failed until someone acts on it — sureops does not automatically retry it.
  1. Check Settings → Integrations to confirm GitHub’s health is green — re-authenticate if permissions were revoked
  2. Contact your sureops support contact to have the failed push retried