Premium Support for GitHub Enterprise is a paid, supplemental support offering for GitHub Enterprise customers. With Premium Support, in addition to receiving support through an online portal, you can also receive support over the phone.

Note: The terms of the Premium Support Plan are subject to change without notice and are effective as of September 2017.

In addition to all of the benefits of Standard Support for GitHub Enterprise, Premium Support offers:

  • Written support through our support portal 24 hours per day, 7 days per week
  • Phone support 24 hours per day, 7 days per week
  • A Service Level Agreement (SLA) with guaranteed initial response times

For more information about Standard Support, see "About GitHub Enterprise Support."

In this article:

Installing GitHub Enterprise releases

To ensure that your GitHub Enterprise instance is stable, you must install and implement GitHub Enterprise releases. Installing GitHub Enterprise releases ensures that you have the latest features, modifications, and enhancements as well as any updates to features, code corrections, patches or other general updates and fixes to GitHub Enterprise.

GitHub will not provide Premium Support if you're not on a currently supported or maintained version.

Signing up for Premium Support

To sign up for Premium Support for GitHub Enterprise, you can contact our account management team or call +1 (877) 448-4820.

Contacting GitHub Enterprise Premium Support

Premium Support customers can use the support site to report incidents in writing, or call +1 (888) 793-6707 or +1 (628) 600-0888 to receive English-language support over the phone.

Hours of operation

The Premium Support team is available 24 hours a day, 7 days per week. We offer limited support during holidays. For more information on holidays GitHub Enterprise Support observes, see the holiday schedule at "About GitHub Enterprise Support."

Service Level Agreement response times

For tickets you submit, support is available 24 hours a day, 7 days per week. The initial response time guaranteed by the SLA is dependent on the severity level of the incident. Response time begins when GitHub Enterprise Support sets the severity level of the incident ticket. A response does not mean the issue has been resolved.

Incident severity level Initial response time
Urgent 30 minutes
High 4 hours

Preparing to submit an incident

Note: When submitting an incident, the person contacting the Premium Support team should be knowledgeable in your internal systems, tools, policies, and practices and be a proficient user of GitHub Enterprise. Your contact should have full access and permissions to any services that are required to troubleshoot the incident. Your contact should also be authorized to make the recommended changes to your network and any applicable products.

Before submitting an incident, you should:

  • Make sure you can reproduce the incident
  • Obtain information that can help GitHub track, prioritize, reproduce, or investigate the incident
  • Be prepared to provide a full description of the issue and expected results

Submitting an incident

When submitting an incident, you should:

  • Categorize the issue (for example, as a technical question, defect, license request, or enhancement request)
  • List steps to reproduce the issue and relevant data
  • Provide any applicable log files and support bundles (de-identified of sensitive data if appropriate)
  • Provide exact wording of all issue-related error messages
  • Describe any special circumstances surrounding the discovery of the issue (for example, the first occurrence or occurrence after a specific event, frequency of occurrence, business impact of the problem, and suggested urgency)
  • Determine if there is an existing incident number in any ongoing communications with GitHub
  • Provide a skilled GitHub administrator as a point of contact for Urgent severity incidents
  • Provide a business justification when the incident severity is Urgent

Assigning a severity level to an incident

GitHub Enterprise Support sets the severity level of incident tickets and has the sole discretion to modify the severity level. Incident tickets can have one of four severity levels: Urgent, High, Moderate, or Low.

Severity level Description
Urgent This severity level is the highest priority and receives first attention. Urgent severity tickets include:
  • Fatal system failure such as a server that is down or unresponsive
  • Outage that impacts critical system operations
  • Security breach
  • Expired license
High This severity level indicates incidents that impact business operations. High severity tickets are bug reports for critical parts of the product.
Moderate This severity level indicates technical requests including configuration changes and third-party integrations. Moderate severity tickets are bug reports for non-critical parts of the product.
Low This severity level indicates non-technical requests. Low severity tickets include:
  • General how-to questions and feature requests
  • Purchase requests
  • Training requests
  • Health checks

Resolving and closing issues

For issues that can be solved, GitHub Enterprise may provide a resolution in the form of an explanation, recommendation, usage instructions, workaround instructions, or by advising you of an available release that addresses the issue.

If you use a custom or unsupported plug-in, module, or custom code, GitHub Enterprise Support may ask you to remove the unsupported plug-in, module, or code while attempting to resolve the issue. If the problem is fixed when the unsupported plug-in, module, or custom code is removed, GitHub Enterprise Support may consider the issue resolved.

GitHub Enterprise Support may close issues if they're outside the scope of support or if multiple attempts to contact you have gone unanswered. If an incident is closed due to lack of response, you can request that it be reopened.

Receiving credits for missed ticket responses

If you don't receive an initial response within the guaranteed response time to more than four incidents in a given quarter based on GitHub's fiscal year, you're eligible for a credit. To honor the SLA, GitHub will refund 20% of the quarterly Premium Support fee in cash. To receive the refund, you must submit a credit request.

The credit request must be made within 30 days of the end of the quarter during which the incident tickets were not responded to within the designated response time. Credit requests will not be honored if the respective deadline has passed. Once the respective deadline passes, you have waived the ability to claim a refund for the qualified credit.

To receive a refund, you must submit a completed credit request to supportcredits@github.com. To be eligible, the credit request must:

  • Be received by GitHub by the end of the 30th day after the quarter in which the four qualifying credits occurred
  • Include “Credit Request” in the subject line

The following information must be included in your credit request:

  • Date (The date must be within 30 days after the quarter based on GitHub’s fiscal year end in which the claims occurred [January 31, April 30, July 31, or October 31].)
  • Customer contact (You must specify both name and email address.)
  • Customer address
  • Qualifying credits (You must provide the date of each qualifying credit and the associated ticket number.)