With Premium Support for GitHub Enterprise, you can:

• Receive all the benefits of GitHub Enterprise support. For more information, see "About GitHub Enterprise Support."
• Submit individual issues, as incidents, over the phone.
• Enter into a Service Level Agreement (SLA) and receive credits if tickets are missed.

Installing GitHub Enterprise releases

To ensure that your 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. If you do not install releases, your your GitHub Enterprise instance may be unusable and GitHub will not be required to provide Premium Support even if applicable fees have been paid.

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.

Receiving Premium Support help

You can use the support site to report incidents and receive support. To receive English-language support over the phone, you can call +1 (888) 793-6707 or +1 (628) 600-0888.

Hours of operation

The Premium Support team is available from 5:00 a.m. to 5:00 p.m. Pacific Time (PT). We offer limited support during holidays. For more information on holidays GitHub Enterprise Support observes, see the holiday schedule at "About GitHub Enterprise Support."

Preparing to submit an incident

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 and requires 24x7 attention

Assigning a severity level to an incident

GitHub sets the severity level of incident tickets and has the sole discretion to modify the severity level. Incident tickets can have the following 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 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 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 may consider the issue resolved.

GitHub 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.

Service Level Agreement response times

For tickets you submit, support is available 24 hours a day, Monday through Friday. The initial response time guaranteed by the SLA is dependent on the severity level of the incident. Response time begins when GitHub 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

Receiving credits for missed ticket responses

If you don't receive an initial response 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.)