> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Know Your Lane Admin vs Support

> Guide for enterprise GitHub administrators on triaging incidents, determining ownership between org configuration and GitHub infrastructure, and preparing precise evidence before escalating to GitHub Support

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](https://support.github.com). 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."](https://mintcdn.com/kodekloud-c4ac6d9a/IdpF6mT8Tun72cng/images/GitHub-Administration-Certification/Administration-and-Support/Know-Your-Lane-Admin-vs-Support/when-to-troubleshoot-or-escalate.jpg?fit=max\&auto=format\&n=IdpF6mT8Tun72cng\&q=85\&s=374b123076a864b89a02698ded22f886)

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).](https://mintcdn.com/kodekloud-c4ac6d9a/IdpF6mT8Tun72cng/images/GitHub-Administration-Certification/Administration-and-Support/Know-Your-Lane-Admin-vs-Support/github-access-triage-inside-outside.jpg?fit=max\&auto=format\&n=IdpF6mT8Tun72cng\&q=85\&s=86d5bfbbbf19c09bb25f6b005066e463)

Your very first check should be the GitHub Status dashboard at [status.github.com](https://www.githubstatus.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](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.](https://mintcdn.com/kodekloud-c4ac6d9a/IdpF6mT8Tun72cng/images/GitHub-Administration-Certification/Administration-and-Support/Know-Your-Lane-Admin-vs-Support/github-status-services-incident-banner.jpg?fit=max\&auto=format\&n=IdpF6mT8Tun72cng\&q=85\&s=9db7c3078d9c5a7a90a45e066d57c8b0)

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

| Problem | Owner | First-actions / Runbook |
| - | - | - |
| User lost 2FA or locked out | Organization administrator | Remove the user from the organization so they can use GitHub’s account recovery flow. Follow the user through the [Account Recovery process](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-account-security/account-recovery), then re-invite. Note: GitHub Support will not bypass 2FA. |
| SAML SSO or SCIM provisioning failure | Joint: your IdP admin + GitHub admin | Check IdP logs, verify SCIM bearer token validity, confirm attribute mappings and SAML certificate validity (expiry, issuer, metadata). Renew certificates and correct mappings as needed. |
| Self-hosted runner outage | Your infrastructure team | Inspect host health, service logs, network connectivity, and VM/container status. Restart runner service or scale infrastructure as appropriate. |
| GitHub-hosted runner outage | GitHub infrastructure / Support | Verify status, collect job IDs and timestamps, then open a ticket if the status page shows no incident. |
| GitHub API 503 or service degraded | GitHub Support / infrastructure | Confirm via status page; if status is green, gather request IDs, timestamps, and API responses and open a support ticket. |

Two detailed examples

1. Two-factor authentication (2FA) and account recovery

* Ownership: Your organization.
* Why: For security, [GitHub Support](https://support.github.com) 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](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-account-security/account-recovery).
  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.

2. 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:

```text theme={null}
Summary: SCIM provisioning failure for organization "ACME Engineering" — persistent 401

Details:
- First observed: 2026-10-30T14:00:00Z (UTC)
- Symptom: SCIM provisioning returns 401 on /scim/v2/Users requests
- Actions attempted: regenerated SCIM token, re-synced IdP, verified network connectivity
- Attached: full API response payload, request trace IDs, and IdP logs for the failure window
```

Table: What to collect before contacting Support

| Item | Why it helps |
| - | - |
| Timestamps (UTC) | Pinpoints incident window |
| Request IDs / Trace IDs | Lets engineers find backend logs |
| Full API response payload | Shows exact error codes and body |
| Screenshots / Logs | Visual or textual proof of the symptom |
| Scope (user/org/repo) | Helps route to the correct team |
| Steps attempted | Prevents duplicate troubleshooting |

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](https://www.githubstatus.com) 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

* [GitHub Status](https://www.githubstatus.com)
* [GitHub Support](https://support.github.com)
* [Account recovery](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-account-security/account-recovery)

> [card] [Watch Video](https://learn.kodekloud.com/user/courses/github-administration-certification/module/dd75e8c3-9cc0-462c-8bdd-8ad78690d5dc/lesson/b1d93856-52e9-40c4-9783-b228e96a9f54)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.