Skip to main content
One of the most practical skills you will develop as an enterprise GitHub administrator is knowing exactly when a problem is yours to fix and when it requires escalation to GitHub Support. In high-pressure incidents—when developers are panicking—you need a repeatable triage framework to determine ownership quickly and act confidently.
A flowchart titled "When to Troubleshoot vs. Escalate" showing an Enterprise Administrator asking "Whose problem is it?". Arrows branch to two options: "Yours to Fix — Our configuration" and "Escalate to GitHub Support — Their infrastructure."
Think of your role like an emergency room triage nurse. When a developer reports, “I can’t access GitHub,” that is a symptom, not a diagnosis. Your first question must always be: is the problem inside our walls (our configuration) or outside our walls (GitHub’s infrastructure)?
A slide using a medical triage metaphor to troubleshoot the complaint "I can't access GitHub." It asks whether the problem is inside the facility (our configuration) or outside (GitHub).
Your very first check should be the GitHub Status dashboard at status.github.com. If GitHub is reporting degraded performance or an outage, administrative changes in your org will not resolve it.
Quick triage checklist
  • Check the GitHub Status dashboard: https://www.githubstatus.com
  • Ask the reporter for exact time, affected users, and a clear description of the error (screenshots, request IDs).
  • Determine scope: single user, single repo, organization-wide, or global.
  • Verify whether impacted components are GitHub-hosted (infrastructure) or org-managed (configuration/IdP/runners).
A screenshot of a status page (status.github.com) listing services like Git Operations, Webhooks, Packages, Codespaces, Actions and API Requests with green, orange and red indicators for operational, degraded performance, and partial outage. A small banner on the right says "Tweaking your admin panel" and the page shows an "Incident in progress" notice.
If the status page shows any degraded performance or incidents, treat the problem as GitHub infrastructure first. If the status is green, proceed to investigate organization-side causes (identity, configuration, self-hosted infrastructure). Ownership examples and runbooks Two detailed examples
  1. Two-factor authentication (2FA) and account recovery
  • Ownership: Your organization.
  • Why: For security, GitHub Support will not bypass 2FA.
  • Runbook:
    1. Remove the affected user from the organization (so they can use account recovery).
    2. Direct the user to the Account Recovery documentation.
    3. Once they regain access, re-invite them to the org and verify access.
Never attempt to bypass two-factor authentication yourself or request that Support bypass it—this is a security policy and cannot be done.
  1. SAML SSO and SCIM provisioning failures
  • Ownership: Administrative — you + your IdP admin.
  • Common causes: expired SAML certificates, expired SCIM bearer token, attribute-mapping errors.
  • Troubleshooting: check IdP logs for failed SAML assertions, verify SCIM token expiry, confirm attribute mappings (username/email) and certificate chain validity. After fixes, test provisioning with a single user before bulk operations.
Opening a support ticket — be precise A vague ticket slows triage. Provide concise, actionable evidence: What to include in a ticket:
  • Exact timestamps (UTC), e.g., 2026-10-30T14:00:00Z
  • Scope (user, org, repo, enterprise)
  • Component affected (API, Actions, Runners, Web UI)
  • Full API response payloads, request IDs, and trace IDs when available
  • Screenshots or logs showing the error
  • Steps already tried and results
Example ticket body:
Table: What to collect before contacting Support Exam-focused ownership summary
  • User loses 2FA: Administrator must remove the user from the organization so they can complete GitHub account recovery and then be re-invited.
  • SAML certificate expiry or SSO misconfiguration: Joint responsibility between the GitHub admin and the IdP admin—check certificates, mappings, and IdP logs.
  • GitHub API 503 / degraded service: Infrastructure issue for GitHub Support—verify the GitHub Status dashboard and, if the status is green, collect diagnostics before opening a ticket.
Final guidance Use this repeatable triage approach during exams and in real incidents:
  1. Verify GitHub service health (status.github.com).
  2. Narrow the scope (user vs. org vs. global).
  3. Determine ownership (configuration/IdP/self-hosted infra vs. GitHub infra).
  4. Collect precise evidence and escalate with the details required to resolve the incident quickly.
References

Watch Video