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
- Signing up for Premium Support
- Contacting GitHub Enterprise Premium Support
- Hours of operation
- Service Level Agreement response times
- Preparing to submit an incident
- Submitting an incident
- Assigning a severity level to an incident
- Receiving credits for missed ticket responses
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
Contacting GitHub Enterprise Premium Support
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|
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.
|Urgent||This severity level is the highest priority and receives first attention. Urgent severity tickets include:
|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:
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 email@example.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.)